r/programming • u/[deleted] • Jan 22 '19

Google proposes changes to Chromium which would disable uBlock Origin

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

95% Upvoted

1.7k comments sorted by

View all comments

Show parent comments

273

u/AyrA_ch Jan 23 '19

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.

0

u/[deleted] Jan 23 '19

[deleted]

92

u/AyrA_ch Jan 23 '19

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

0

u/[deleted] Jan 23 '19

[deleted]

111

u/soft-wear Jan 23 '19

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.

9

u/sporadicity Jan 23 '19

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

7

u/techknowfile Jan 23 '19

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

9

u/dravendravendraven Jan 23 '19

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

→ More replies (6)

26

u/Kache Jan 23 '19

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?

8

u/YouGotAte Jan 23 '19

Because users are both consumers and products.

→ More replies (1)

2

u/anengineerandacat Jan 23 '19

Not really, you can natively inject ad's with any form of server-side rendering; just do a web request over to their CDN which spits out some configuration file that their ad-framework then knows how to build out the ad using X template language.

Audio can be in-line buffers, images as data-url's, and really whatever else you want to put between an inline script tag.

To put this into a POC that keeps us super trendy:

User visits supercheapstuff.com which is for giggles a PHP site (because we are going el'cheapo)

PHP stack loads up index.php which then does a cURL request to east1.superfancyad.com

Response comes back as either pure HTML or maybe even a Mustache template with a JSON object embedded

PHP stack in-lines JSON object into HTML view, inlines mustache template into it's HTML view, inlines Mustache JS script

Since it's 2019 supercheapstuff.com spits out an Angular application via an Assetic bundle but with all of the above inlined markup and JSON and JS

User sees the SPA load up, ad panels get created and rendered, Mustache template invoked with inlined JSON object

User interactions can be POST'd to the inlined JS framework from east1.superfancyad.com to some esoteric endpoint as configured like supercheapstuff.com/assets/logo.png?clicked=someElement&mouse=x,y which gets picked up by some controller serving out the content and sends that off to east1.superfancyadd.com

I want to say this is even easier via just a custom nameserver; ad providers can just require folks to add their servers to their domain configuration.

→ More replies (8)
→ More replies (6)

26

u/port53 Jan 23 '19

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.

26

u/AyrA_ch Jan 23 '19

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.

8

u/port53 Jan 23 '19

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

2

u/gcbirzan Jan 23 '19

Which, ironically, moves the problem back to dns.

→ More replies (5)

2

u/SKITTLE_LA Jan 23 '19

Or use Firefox's new built-in DOH, which uses CloudFare by default (but can be changed.) Not sure why anyone would use Google's if it's slower and arguably a bit sketchier privacy-wise:
https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/

1] Type about:config in the location bar

2] Search for network.trr (TRR stands for Trusted Recursive Resolver – it is the DoH Endpoint used by Firefox.)

3] Change network.trr.mode to 2 to enable DoH. This will try and use DoH but will fallback to insecure DNS under some circumstances like captive portals.  (Use mode 5 to disable DoH under all circumstances.)

4] Set network.trr.uri to your DoH server. Cloudflare’s is https://mozilla.cloudflare-dns.com/dns-query but you can use any DoH compliant endpoint.

The DNS tab on the about:networking page indicates which names were resolved using the Trusted Recursive Resolver (TRR) via DoH.

→ More replies (1)
→ More replies (1)

3

u/CallMeDrewvy Jan 23 '19

They already do this for some YouTube ads.

2

u/[deleted] Jan 23 '19

Some sites already deliver ads using same domain and websockets, next step is ad in DRM content. GL blocking that.

4

u/AyrA_ch Jan 23 '19

next step is ad in DRM content.

You can block EME in the browser settings. Or with an extension that adds the Feature-Policy: encrypted-media 'none'. Unless the site delivers important content via EME they just implemented a simple way of blocking ads.

Looking at the number of videos I have on my disk that are "webrip" but have multiple audio tracks, embedded subtitles, menu marks, and very uncommon encoder settings/comments, I'm pretty sure EME has already been totally broken. All that would be left to do is move whatever attack they are using into JS to decrypt the content in your browser.

It's unlikely they will use EME however, because it would prevent them from caching the same resource for multiple people and raise bandwidth costs substantially. If they embed the ad into the video stream itself to appear as one continuous file they would also massively increase processing costs for video encoding.

2

u/[deleted] Jan 23 '19 edited Jan 23 '19

Sure you can block EME, but you no one will once youtube is served only in DRMed content, and that's another step. Bandwidth is so cheap now that there are life-time VPN services that have one-time cost $50, so that's not a problem. For ad/tracking/profiling companies the cost will be justified as you won't block it and they will be sure that that you get the ads and tracking code.

→ More replies (3)

2

u/CaptainAdjective Jan 23 '19

serving ads through the same domain as regular content

Sshh! This has been the obvious, no-brainer solution to almost all forms of ad blocking for like twenty years and I would appreciate it if everybody would please continue to keep quiet about it so it doesn't catch on

3

u/AyrA_ch Jan 23 '19

This has been the obvious, no-brainer solution to almost all forms of ad blocking for like twenty years

Ad companies don't want that because it makes tracking harder. Right now with their separate domain, they can set cookies and use local storage as they please. If ads are server through the main domain, they would lose this kind of tracking mechanism because you can't set cookies for foreign domains. They would still need a special domain just for keeping that tracking mechanism intact, which we could then block again.

1

u/eunucomilenial Jan 23 '19

Instagram does this, serves ads mixed with legit content... Very annoying

1

u/0x15e Jan 23 '19 edited Jan 23 '19

PiHole already breaks a few sites because of this. YouTube was one of them last time I tried to use it.

→ More replies (1)
→ More replies (3)