Chromium: network requests bypass blockers

Unfortunately, it doesn't. Just tested with Chromium 78.0.3904.70.

 

Thx, I confirmed too, not sure if it's related to "slow network" description. For this particular issue I'm less concerned now, as even preconnect is TCP handshake (& TLS negotiation) only, meaning HTTP has not started so no download/upload (e.g. cookie, referrer, UA) occurs; however, trackers see your IP.
More important would be finding a site using link rel="prefetch" and see if it's really blocked. Obviously Pi-hole is not suitable to test this, chrome://net-internals, Wireshark, or Fiddler is required.

 

Yes, and that's certainly nothing I'm willing to accept.

 

It's too bad Microsoft didn't back Firefox instead of Chromium. Given the much smaller user base and that right now Google is a big part of their funding its a legitimate question to wonder how long they will survive. I don't mean in the intermediate future but down the road.

 

@summerheat are you able to test Edge Chromium built-in Tracking Protection set to Strict, maybe Edge Dev version? I would appreciate it as I have no way to test. I'm currently trying out the built-in feature with Privacy Possum, so if you could test this combo it would be greatly appreciated as well. TIA.

 

I'm sorry but I'm using Linux, and Edge Chromium is not available for that OS. But I'm sure there are Windows applications which let you monitor all network requests.

 

Has Chromium-Edge dropped chrome://net-internals? Note in case of WP, no connection goes to these ad/tracker sites, so you only need to look at DNS queries (e.g. Sysmon can do this). Also I once explained how to use Fiddler somewhere in this forum, tho it was for exploit-replay.

 

Prefetching and WebRTC are the first things I always disable from about:config in Firefox.
They are nothing but privacy nightmare.

It's sad that vanilla Chrome & Chromium must be so difficult to make privacy respecting....

 

Well, it's not only "difficult" - it rather seems that this specific issue is not possible to prevent in Chromium at all.

Granted, if you're using dnsmasq, unbound, dnscrypt-proxy, Pi-hole or a big hosts file on your system to block ads and trackers, this problem can be mitigated. But this should not be necessary at all.

 

Looking at the example of washingtonpost, should the blocked items in UBO/Firefox and UBO/Chrome be different then?

 

Just to make sure, you're not that fanboy who is the maintainer of EasyList, right?
Well, even w/out this the blocked items btwn the two browsers are not always the same. But in this case, the blocked "items" will be the same, while blocked "requests" won't. Those bypassed requests were nothing to do w/ page contents, they're only DNS requests - these trackers will know nothing about you. The story is bit different if a site uses 'link rel="preconnect"' tho.

 

Here is the notification from Edge: The net-internals events viewer and related functionality has been removed. Please use edge://net-export to save netlogs and the external catapult netlog_viewer to view them.

 

I use Adguard in my chromium browsers as it blocks a lot of stuff I can't get blocked in ubo. Firefox is still my default browser.

 

@Bertazzone So it's the same as Brave, IDK why they removed a useful tool.
@IvoShoen Both extension simply block what are on their filter lists. So that's not a matter of extension except that there are differences in supported syntax. If you use AdGuard filters on uBO ofc it blocks less than AG which fully supports AG syntax.

 

I happened to find this thread is referenced in MT, but same as this thread there seems to be a little confusion. To clear things up I'll summarize what I wrote.
When you see logs pay attention to what they stand for. In case of WP, the cause of the issue is <link rel="dns-prefetch" href="//sometracking.com"> which instructs browser to make DNS prefetch and on Chromium it overrides users' tweak. So if the logs are about DNS queries, you'll see those of trackers only on Chromium but it shouldn't matter as NO connection at all goes to tracker. If you can't trust your DNS you have greater problem. If you doubt use any packet capture tool, my favorite is Fiddler. There's another thing Chromium allows websites to override, <link rel="preconnect" href="//example.com">. This is no more only DNS prefetch but proceeds to TCP handshake (and TLS negotiation in case of https). This means still no data (e.g. cookie, referrer, UA) goes to tracker, what the tracking server can see are at most your IP and some of TLS info such as supported protocols. If it matters is more of a personal problem, also depends on your situation (e.g. if you use static IP). <link rel="prefetch" and <link rel="prerender" tries to proceeds further but now uBO can block them on Chromium. To me more problematic limitation on Chromium is no support for HTML filtering. It's about removing capability than blocking, and there are cases HTML filtering is preferred.

(Off-topic: glanced at the thread there are common errors, say, both Disconnect simple_ad and malvertising lists are different from Firefox TPL despite all are from Disconnect, compare them by yourself. I respect Kees but his filters there include errors and nonoptimal syntax. I'm not starting cross-forum conversation nor criticizing)

 

I agree, even though I don't understand all the technical details.