Ublock: Will HTTP2 multiplexing and server-push features circumvent uBO?

[RoxKilly]

Over at the ghacks-user.js project, we've been discussing the benefits of allowing/disabling HTTP/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:

1. Make sure HTTP/2 is enabled. In FF 53, it's ON by default. The following prefs should all be set true

network.http.spdy.enabled
network.http.spdy.enabled.deps
network.http.spdy.enabled.http2

1. Add the following rules to uBO. Note that I block certain image URLs to test uBO's effectiveness under HTTP/2.

www.http2demo.io * 1p-script noop
www.http2demo.io * 3p-frame noop
www.http2demo.io * inline-script noop
www.http2demo.io http://1153288396.rsc.cdn77.org/http2/tiles_final/tile_1 image block

1. Clear the browser cache. Then load this page: http://www.http2demo.io/ . It will open many connections to 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 with tile_1 are blocked. Notice also that the big image is missing some blocks:
   
   

step 4 is flawed: ignore this result

1. Clear the browser cache. Then press the Run HTTP/2 Test button. This time, uBO is unable to block the same content.
   
   

My question

Can uBO filter HTTP/2 network requests? Would connections be effectively prevented?

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

[seanrand]

Uhm. You do realize that the second set of images is loaded from a different server? 😅
http://1153288396.rsc.cdn77.org/ vs https://1906714720.rsc.cdn77.org/

[RoxKilly]

No I didn't notice! let me rerun the test.

Results look a LOT better. In Firefox 53, uBO sucessfully blocked HTTP/2 content!!! I had to add the following dynamic url filter:

www.http2demo.io https://1906714720.rsc.cdn77.org/http2/tiles_final/tile_1 image block

[anewuser]

@RoxKilly Please close this issue and read this carefully before posting here again: CONTRIBUTING.md.

[RoxKilly]

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 discourse.mozilla-community.org

[gorhill]

wouldn't this qualify as an issue with the filtering engine itself?

What issue? You corrected your first comment that uBO does indeed block properly whatever you wanted it to block.

[RoxKilly]

@gorhill wrote:

What issue? You corrected your first comment that uBO does indeed block properly whatever you wanted it to block.

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.

[gorhill]

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.

[uBlock-user]

It's always been working ever since HTTP/2 was implemented in Chromium that was way before Firefox implemented support for that itself.