-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Will HTTP2 multiplexing and server-push features circumvent uBO? #2582
Comments
Uhm. You do realize that the second set of images is loaded from a different server? 😅 |
Hi @anewuser Help me out: wouldn't this qualify as an issue with the filtering engine itself? If you guys feel it does not qualify, I would be happy to repost at |
What issue? You corrected your first comment that uBO does indeed block properly whatever you wanted it to block. |
@gorhill wrote:
yeah uBO seems to block over HTTP/2 so that's resolved. By referring to "issue", I'm getting at something slightly different. If I believed there was a connection protocol that uBO failed to block and I have test results to share, is the right place to post that stuff here or on Mozilla Discourse? That's what I mean by "issue": as in, would you consider it be an issue legitimate to be posted here or a mere discussion topic that should be on Mozilla Discourse. |
The webRequest API normalizes all requests so that uBO does not have to concern itself with whatever underlying revision of the HTTP protocol is in use -- that's way below uBO's scope. If ever there was a case of network requests not relayed to uBO through the webRequest API, then this a browser issue. |
It's always been working ever since HTTP/2 was implemented in Chromium that was way before Firefox implemented support for that itself. |
Over at the
ghacks-user.js
project, we've been discussing the benefits of allowing/disablingHTTP/2
and it turns out that uBO's ability to do its work could play a big role in users' decision on the matter. I'd appreciate any thought you have.The Issue
HTTP/2 is a new spec meant to significantly reduce header and connection overhead. Here is a very simple intro as well as a basic FAQ. The protocol has at least two features with important privacy implications and I wondered whether uBO would protect its users from them:
Multiplexing: whereas in HTTP/1, the browser establishes one connection for each asset it wants to download, in HTTP/2 multiple assets, possibly from multiple hosts, can be transmitted over a single connection
Server-Push: whereas in HTTP/1, the browser first fetches the HTML, then discovers what else it needs and then fetches additional assets (CSS, JS, Fonts...), in HTTP/2 the server can "push" all assets it believes the browser will need as soon as the browser makes the first request
Let's test
I ran a quick test on this site using Firefox 53 and results don't look promising. To replicate:
true
cdn77.org
to download image sections that are then stitched together to make the big image on the left of the page. The logger shows that all images with names starting withtile_1
are blocked. Notice also that the big image is missing some blocks:step 4 is flawed: ignore this result
Run HTTP/2 Test
button. This time, uBO is unable to block the same content.My question
Edit
My test was flawed because I didn't realize that HTTP/2 files were being loaded from a different server. In fact uBO succeeded. See my next post below
The text was updated successfully, but these errors were encountered: