CNAME Cloaking
Romain Cointepas (Hacker News):
A suitable name for this method would be CNAME Cloaking, and it is used to disguise a third-party tracker as first-party tracker. In this case, they are also purposely obfuscating this behind a random subdomain, with a CNAME to a generic and unbranded domain.
With CNAME Cloaking, many problems arise that makes it realistically impossible to block this:
- Browser extensions are not allowed access to the DNS layer of the request — i.e., they can’t see the CNAMEs.
- When each website loads third party trackers by calling something like a3ksbl.website.com, privacy-protection tools now have to figure out which subdomain is a front for CNAME Cloaking, for tens of thousands of websites. […]
- With each website now having its own subdomain cloaking the third-party tracker, those tools need to include as many rules as there are websites using this CNAME Cloaking method. Blocking a third-party tracker went from one rule to thousands.
And newer browsers have relatively low limits for the number of allowed rules.
See also: Wolfie Christl.
Update (2019-11-26): Jeff Johnson:
The endgame has to be disabling JavaScript.
As long as sites can execute arbitrary code in your browser, you’re doomed. Web programmers will continue to find more clever and evil hacks.
I continue to be frustrated that, while most others things in Safari can be controlled by site, JavaScript is just a single control - on or off for everything.
Would it be too much to have finer control?
3 Comments RSS · Twitter
CNAME cloaking and DNS over HTTP(s) are both about the same thing: breaking the ability for normal people to deploy DNS-based tracking & surveillance blockers. I've been doing this for my own networks for a decade and it has always worked perfectly. In a year, it will be a lost cause, precisely because it is so effective.
Not sure the focus should be on CNAME per se. After all, if a publisher can be convinced to add a CNAME entry for one of their subdomains pointing to a server belonging to an ad/tracking provider, they can just as easily be convinced to add a nameserver (NS) entry for same, in which case the delegation would be invisible to the DNS stub resolver sitting in the endpoint (much less to the tracking prevention extension), as the recursive resolver (i.e. the machine, sitting in your ISP if you use the IP provided as part of the PPP/PPPoE/DOCSIS connection information, or something like 8.8.4.4 if you overrode with that (do those protocols use DHCP? I can never remember)) would handle that already.
(I'd point to resources to help you make sense of that if you're not completely familiar with DNS operation, but my main reference is Stéphane Bortzmeyer, in French, sorry…)
What boggles the mind is the tone of the Criteo email. "Oh, yeah, point one of your subdomains to one of our servers, no big deal, after all people who trust lemonde.fr can trust something coming from us as if it came from you, right?" 😱 This is all the more important as I've started using ad blockers post Meltdown and Spectre.
Would be interesting to see someone can make a 'Click2JavaScript' extension with a better UX than NoScript. I suppose website could always embed the tracking in the main app's JS, though.
