Range requests used by pdfjs are not isolated to URL bar domain
If a server sends the Accept-Ranges header + a (proper) Content-Length Tor Browser is starting range requests that are not isolated to the URL bar domain. You can test this e.g. with https://kpdyer.com/publications/usenix2014-fte.pdf. Works even in a third party context with https://people.torproject.org/~gk/misc/range-request-test.html (your security slider level needs to be below medium-high in this case).
Activity
I think this is due to
getFirstPartyURI failed for https://kpdyer.com/publications/usenix2014-fte.pdfI wonder if we could get that fixed last-minute for 4.5.
Trac:
Description: If a server sends the Accept-Range header + a proper content size Tor Browser is starting range requests that are not isolated to the URL bar domain. You can test this e.g. with https://kpdyer.com/publications/usenix2014-fte.pdf. Works even in a third party context with https://people.torproject.org/~gk/misc/range-request-test.html (your security slider level needs to be below medium-high in this case).to
If a server sends the Accept-Ranges header + a (proper) Content-Length Tor Browser is starting range requests that are not isolated to the URL bar domain. You can test this e.g. with https://kpdyer.com/publications/usenix2014-fte.pdf. Works even in a third party context with https://people.torproject.org/~gk/misc/range-request-test.html (your security slider level needs to be below medium-high in this case).
-
I was wondering that, too. There are definitely larger pdfs that get rendered without range requests. Then there are large non-pdf downloads where the server is sending an Accept-Ranges header but no range requests are issued by the browser. So far, I don't have non-pdf range requests seen which would clarify if that is purely pdf related.
-
Retitling this bug as it seems only range requests issued by pdfjs have this problem. See, e.g. http://hpr.dogphilosophy.net/test/opus.opus or other tests on http://hpr.dogphilosophy.net/test/.
Trac:
Summary: Range requests are not isolated to URL bar domain to Range requests used by pdfjs are not isolated to URL bar domain -
We could disable range requests easily in pdfjs but that is affecting rendering speed with unknown impact. Thus, this is no great idea to do without testing at least in one alpha. Fixing the root cause of the problem, an extension issuing XHRs and thus having no window associated to the channel, is no option for an untested stable patch either. Therefore, removing this issue from the 4.5 radar. :(
Trac:
Keywords: tbb-4.5-alpha deleted, N/A added
Owner: gk to tbb-team PDFs, which are not affected, are going through catchall circuit too when PDF Download button is pressed. UPDATE: this is one of two issues of #17933 (moved).
Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Reviewer: N/A to N/AAnd its OCSP requests too:
[05-29 18:16:40] Torbutton INFO: tor SOCKS: http://ocsp.usertrust.com/ via --unknown--:acc796c227a065d5b876d251f00beb87Replying to gk:
Works even in a third party context with https://people.torproject.org/~gk/misc/range-request-test.html (your security slider level needs to be below medium-high in this case).
Security Error: Content at https://kpdyer.com/publications/usenix2014-fte.pdf#disableRange=true may not load data from https://people.torproject.org/~gk/misc/range-request-test.html. Load denied by X-Frame-Options: https://kpdyer.com/publications/usenix2014-fte.pdf#disableRange=true does not permit cross-origin framing. (unknown)Hrm, does PDF.js support Private Browsing Mode?
Patch to disable range-based requests in pdf.js. Fixes the domain isolation issue, at the expense of usability. With this pref flipped, the entire pdf must be downloaded before being viewed and interacted with.
Trac:
Keywords: TorBrowserTeam201801 deleted, TorBrowserTeam201801R added
Status: assigned to needs_review-
Okay, let's try that in the alpha series a bit. I admit, though, I am a bit skeptical whether the possible usability issues are worth it. We'll see.
But before that, two things:
- s/cannot/can/ (it seems to me one negation is already enough :) )
-
extension-overrides.jsis the wrong place for the patch. We don't treatpdf.jsas en extension but rather as part of the browse core (after all it does not show up in theabout:addonsmenu etc.). So, our usual prefs file,000-tor-browser.js, would be the better place.
Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201801R deleted, TorBrowserTeam201802 added 
Replying to pospeselr:
Unfortunately, the user_pref setting doesn't seem to stick when placed in the usual 000-tor-browser.js, and it gets overwritten by pdfjs initialization code if specified in the usual fashion (verified with an rbm build).
I assume this is the code that is overriding the settings for
pdfjs.disableRangewhen placed in000-tor-browser.js: https://dxr.mozilla.org/mozilla-esr52/source/browser/extensions/pdfjs/content/PdfJs.jsm#79Maybe we should patch the above code instead and also add the the setting to
000-tor-browser.jsas a reminder that we care about the value forpdfjs.disableRange. Probably gk should decide which approach we want to use.How bad is performance when loading a large PDF with this change in place? I assume "time to first page display" increases significantly.
Trac:
Status: needs_review to needs_information
