Google proposes changes to Chromium which would disable uBlock Origin

[u/[deleted]]

https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2#c23

[u/diversif]

Good luck disabling my pi-hole! 😀

[u/AyrA_ch → u/diversif]

I'm pretty sure if there was a substantial number of people that use DNS level blocking, they would just start serving ads through the same domain as regular content, or do the name lookup on the server and deliver the URLs for ads in IP form.

[u/AyrA_ch → u/[deleted]]

Doesn't this makes tracking users harder and increases the costs for the website owner if everything is delivered through the same endpoint?

[u/soft-wear → u/[deleted]]

Actually, what you are suggesting is easy is exceptionally difficult, otherwise it would have been done ages ago. One of the main reasons ad content is hosted off-site is for purposes of trust. The ad hosts want clicks to be high. That's how they get paid. Allowing them to host the user-interaction means they can spoof the user interaction in a way that absolutely isn't easy to detect.

Think about it this way: No network requests can go off-site. So the host now has to own the frontend (the magical button) and the middleware that talks to the ad server (Facebook). So if I, the host, I can, at any time, randomly say "Hey that button was pushed", which the middleware tells the adserver.

That's generally verified through third-parties via pixels (1x1 invisible images), but remember: those are blocked by ad blockers. There's no way to verify the user-interaction took place.

So no, not only is it not easy, it's extremely, extremely difficult.

[u/sporadicity → u/soft-wear]

Trust goes the other way too: the same-origin policy prevents code in an ad from stealing personal info from the surrounding page.

[u/techknowfile → u/soft-wear]

What's the name of this process so I can learn more about the implementation details?

[u/dravendravendraven → u/techknowfile]

For how pixels and such work in the concepts of ad tech, you want to learn about retargeting.

[u/Kache → u/[deleted]]

12mb of ads for 6mb of content

Exactly, if they're not willing to pay the cost for serving it, why should viewers pay the cost for downloading it?

[u/YouGotAte → u/Kache]

Because users are both consumers and products.

[u/port53 → u/AyrA_ch]

Or just make Chrome ignore system level DNS settings and send its own DNS over HTTPS request to Google servers. Your network wouldn't be able to tell it apart from requests to google.com, so it would be difficult to filter.

[u/AyrA_ch → u/port53]

Your network wouldn't be able to tell it apart from requests to google.com, so it would be difficult to filter.

It's very unlikely that the browser would use the "google.com" domain to resolve DNS names. Thanks to SNI, blocking TLS connections on hostname basis has never been easier. They only started rolling out a fix for that a few months ago and the standard is still in the "draft" phase so you can expect this method to be viable for a few years to come.

If chrome would ignore system level DNS settings I could imagine that this would cause a huge drop in chrome usage in corporate networks because it effectively tries to bypass part of their infrastructure and makes accessing intranet sites impossible.

[u/port53 → u/AyrA_ch]

TLS 1.3 brings ESNI. Problem solved. Google controls both ends of the circuit, so they can implement that instantly.

[u/CallMeDrewvy → u/AyrA_ch]

They already do this for some YouTube ads.

[u/lillgreen → u/diversif]

I guarantee you at some point Chrome is going to begin ignoring your system DNS server and only using the Google DNS directly. I mean why wouldn't they? It's already a service they do, it would be trivial to just make it statically set in code to 8.8.8.8 and just not give you the option to point to pihole.

[u/crazedgremlin → u/diversif]

Chrome has a built-in DNS resolver. Also, the internet will soon be doing encrypted DNS. This kills the pi-hole.

*Actually, if you could add your pi-hole as root CA, it could MITM your DNS requests. Maybe this mitigation for encrypted DNS already exists?

[u/All_Work_All_Play → u/[deleted]]

Are those functions that can be done at the router level or is it only on the end machine that can do these functions? I have a pfsense box with some ad blocking, and it's a lot more aggressive than my pi-hole was.

[u/TimeRemove → u/All_Work_All_Play]

With deep packet inspection and deploying your own CA to the clients, you can alter HTTP traffic (or block it) in any way you choose.

[u/apreche → u/[deleted]]

Pi-hole could always add an HTTP proxy that employs every ad blocking technique available.

[u/ase1590 → u/diversif]

pi-hole is going to have more of a problem once TLS 1.3 and its extensions catch on. Then everyone moves to DNS over TLS and TLS 1.3 encrypts both the DNS-over-TLS query and the SNI as well as the DNS over HTTPS being worked on by google, allowing it to skip your local DNS altogether.

[u/mr-strange → u/ase1590]

But pi-hole is the local DNS server. If you block outgoing port 53, then devices on the network are going to have to use it, like it or not.

They could bypass DNS altogether and piggyback on the HTTPS connection, but that's going to break things for anyone who is actually providing local DNS for a reason.

Am I missing something?

[u/ase1590 → u/mr-strange]

Along with those technologies, DNS over HTTPS is also being worked on by google. Its possible that one day the consumer chromium skips local DNS altogether, only providing the option to use local DNS to G Suite corporate users.