Pipeline defense interferes with twitter and flickr photostreams

The Pipelining defense appears to damage flickr photostreams and twitter media streams. In both cases, these sites experience page load issues and dead images.

In brief ad-hoc testing, reducing network.http.pipelining.max-optimistic-requests to 10 seems to allow all images to load, but more testing is needed.

added component::applications/tor browser owner::tbb-team priority::high resolution::worksforme severity::normal status::closed tbb-firefox-patch tbb-testcase tbb-usability-website type::defect labels

Trac:
Cc: isis to isis, gk

Trac:
Keywords: N/A deleted, tbb-testcase added

I've been setting:

user_pref("network.http.pipelining.aggressive", false);
user_pref("network.http.pipelining.maxrequests", 10);

in my prefs.js, and I'm not certain that it entirely fixes the issue, but it appears to help immensely.

Trac:
Status: new to needs_review
Keywords: N/A deleted, mikeperry201406R added

Hrmm.. Well we need to determine if this is due to the additional pipeline backoff logic that disabling "aggressive" mode causes to be used, or if it is simply the reduction in pipeline depth in general that is helping here.

I took a look at the aggressive mode code, and it looks like it also currently governs the depth to which we randomize the pipeline. If you disable aggressive mode, you are also disabling randomizing the depth. I am going to change this in 3.6.2/4.0-alpha-1 so that we can test these prefs independently.

So I am unable to get this to happen on flickr or with twitter.. If someone can give me a site for which it still causes images to get dropped, we can see if either pref makes a difference independently.

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser

Trac:
Keywords: mikeperry201406R deleted, mikeperry201408R added

Trac:
Status: needs_review to needs_information
Keywords: mikeperry201408R deleted, MikePerry201408R added

I can't trigger this bug anymore, not even with http://postersofberlin.tumblr.com/, which has been one of my choice pipelining optimisation test pages for a while.

I tested with both my preferences that I thought were helping

Preference Name	Value
network.http.pipelining.maxrequests	10
and the default:
Preference Name	Value
-----------------	-------
network.http.pipelining.maxrequests	12
and I couldn't see a difference; both seemed fine.

Perhaps we were being affected by one/some of the major CDNs not having their shit together and now they've finally fixed it?

Possible. Untagging this for now.

Trac:
Keywords: MikePerry201408R deleted, N/A added

What is the current status of this ticket?

reducing network.http.pipelining.max-optimistic-requests to 10 Now it is set to 3. Is this randomization level enough for defense? What is the way to go in esr59 where pipelining is removed?

Trac:
Owner: N/A to tbb-team
Sponsor: N/A to N/A
Status: needs_information to assigned
Reviewer: N/A to N/A
Severity: N/A to Normal

Replying to cypherpunks:

What is the current status of this ticket?

I think WORKSFORME. (If not, please reopen with steps to reproduce)

reducing network.http.pipelining.max-optimistic-requests to 10 Now it is set to 3. Is this randomization level enough for defense? As far as this experimental defense goes I think so, yes. But keep in mind this still needs thorough evaluation.

What is the way to go in esr59 where pipelining is removed?

If we want to have an (additional) in-browser defense then adapting HTTP/2 to our needs might be a good strategy.

Trac:
Status: assigned to closed
Resolution: N/A to worksforme

closed

moved to tpo/applications/tor-browser#10355 (closed)