Chromium bypassing uBlock through behind-the-scene requests

[gorhill]

Chromium bypassing uBlock through behind-the-scene requests. Case:

google-analytics.com is blocked through dynamic filtering in order to ensure it will be blocked with 100% certainty.

Yet, despite google-analytics.com being blocked in uBlock, using goproxy shows:

[...]
2015/01/11 13:25:38 [110] INFO: resp 200 OK
2015/01/11 13:25:38 [114] INFO: req www.google-analytics.com:443
2015/01/11 13:25:38 [114] INFO: Sending request POST https://www.google-analytics.com:443/collect
2015/01/11 13:25:38 [106] INFO: req github.com:443
2015/01/11 13:25:38 [106] INFO: Sending request GET https://github.com:443/gorhill/uBlock/issues/counts
2015/01/11 13:25:38 [114] INFO: resp 200 OK
[...]

This occurs when a network request is sent "behind-the-scene". Behind-the-scene requests are requests which are not bound to a specific tab, while uBlock deals only with requests which comes from a specific tab, because it needs to know the context of a request in order to filter properly.

I verified that this serious problem DOES NOT occur with the Firefox version of uBlock.

I was first made aware of these behind-the-scene google-analytics.com network requests in issue #88 of uMatrix. However with uMatrix there is a solution, as it allows to see/block those behind-the-scene requests. Now is time to figure a solution for uBlock as well.

[gorhill]

Ok, it's going to be similar to uMatrix:

• A synthetic http://chromium-behind-the-scene page store to receive behind-the-scene requests
• Opening uBlock's popup while on uBlock's dashboard will bring up all the data related to behind-the-scene requests
• A permanent entry in the network request logger so that one can see whatever network requests occurs in there

For Firefox, that synthetic page store will likely always be empty.

[gorhill]

A behind-the-scene request observed with Firefox:

2015/01/11 14:21:48 [172] INFO: Sending request GET https://safebrowsing-cache.google.com:443/safebrowsing/rd/ChFnb29nLXBoaXNoLXNoYXZhcjgAQAJKDAgBEPeVDBj5lQwgAU

More info.

[Deathamns]

Do you use other extensions on Chrome? It's not rare that extensions use google-analytics to monitor their usage. Chrome even has a tutorial for this.

[gorhill]

@Deathamns Well given that I created the behind-the-scene matrix in uMatrix I definitely know that (something which I warn about it in the wiki).

I have no other extension.

In the present case, it occurs systematically if you refresh this github page for example. There is definitely a behind network request. You can also see it in the network tab in dev tool.

[chrisaljoudi]

@gorhill could this be related to what's going on with this Chromium issue?

It might be worth disabling omnibox predictive preloading to isolate whoever is initiating the request.

[gorhill]

@chrisaljoudi No. Just refresh a github page with network dev tool on. There is a request to google-analytics.com that is not blocked, because its tab id is -1, i.e. a behind-the-scene request (as defined by uMatrix).

[Deathamns]

@gorhill I must have misunderstood it then.
So, the problem is that there is an actual request in this tab, but Chrome thinks that the request happens behind-the-scene (for some reason)...

[gorhill]

Yes, I don't know why, it looks like it's a Github script making that request somewhere in there, I didn't investigate further.

But the real fix for me is to support behind-the-scene requests just like uMatrix, as this discloses everything, including extensions' own network traffic, and this actually simplifies the code as I can assume throughout there is always a page store available for whatever net request.

[gorhill]

So this is a Github script using Navigator.sendBeacon() which causes a behind-the-scene request.

The fact that the data is sent when the page unloads might explain why it is send without a valid tab id, from the browser's point of view, the tab no longer exists.

[kurtextrem]

You could try opening a crbug for that if it's only because of the new Beacon API.

[gorhill]

No, I want to fix it on my side also because I want users to be able to see other behind-the-scene requests, it's also useful to disclose rogue extensions.

[gitarra]

I reckon this isnt supposed to work on Firefox yet, as it doesnt work on 38.0a1? There wasnt any mention on the changelog about different browsers.