Cname / DNS based third party tracking
arxiv.org
arxiv.org
Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss:
1. ALIAS records (not standardized? popularized by Route53) hide CNAME-like pointers. Another variant of this is, some DNS nameservers (like Cloudflare) flatten CNAME records (aka transparently ALIAS endpoints): CNAMEs aren't sent with the answer, that is, you're straight up served the A/AAAA record with IPs (which could easily be third-party). DNSSEC doesn't help here, afaik.
2. The shiny new SVCB/HTTPS records open up another avenue for DNS cloaking. For example, consider this (unverified if correct) record with a chain of pointers:
example.com SCVB IN 0 example.net
example.net CNAME IN example.org
example.org SVCB IN 0 example.us
example.us SVCB IN 1 example.uk (ipv4hint=2.2.2.2, ipv6hint=2:2::2)
example.uk SVCB IN 0 example.de
example.de CNAME IN example.fr
example.fr SVCB IN 1 . (ipv4hint=..., ipv6hint=...)
example.fr SVCB IN 2 example.es (ipv4hint=..., ...)
example.fr SVCB IN 3 example.it (...)
example.fr CNAME IN example.ru
example.es CNAME IN example.it
example.it SVCB IN 1 . (...)
example.it SVCB IN 2 example.ch (...)
example.it A IN 4.4.4.4
example.it AAAA IN 4:4::4
example.ch SVCB IN 0 example.ru
example.ru SCVB IN 1 . (...)
example.ru A IN 3.3.3.3
example.ru AAAA IN 3:3::3
Though it remains trivial to uncloak domains hiding behind SVCB/HTTPS records, implementations have to be careful about what they let through. Flattened CNAMEs and ALIAS records; however, to my knowledge, remain undetectable.
But: All indications are that it is foolish to rely on DNS to discern between first-party and third-party. I mean, I can already run www.example.com on Netlify, app.example.com on Vercel, api.example.com on AWS, and cdn.example.com on Cloudflare... and those endpoints could very well be running anything the cloud providers want (third party).
IP based firewall doesn't suffer these shortcomings, but then, enforcing IP blocks are complicated by Virtual Hosting (multiple web services behind a single IP) and IPv6 (too many addresses to curate and block).
The fact that the technique relies on a CNAME or some other DNS indirection seems to suggest that the ad server or tracker will have a different IP from the website. That may be another weak point in any effort to conceal the fact that some resources referenced in the page or Javascript files are only necessary for advertising purposes. If both content and ad cruft were being served from a single IP, then that might pose more of a challenge in deciphering what to retreieve. I have yet to see that and doubt I ever will.
I am a believer that ultimately whitelisting is more effective than blacklisting. Request what you want, leave the rest. As opposed to letting a browser request everything according to a web developer's wishes, and then you try to block stuff. With extensions, third party assistance, etc.
For interest, what do you use? A standard browser with plugins, or a specialised client?
Today's "standard browser" that runs Javascript is an omnibus, overly complex, kitchen sink program that is inextricably linked to the online advertising industry. Online ads and tracking generally do not work without the help of one of these so-called "standard" browsers.
So does URL based content-blocking. I recently want to block Youtube/Twitter ads on my own, to my dismay, the ads were buried in some deep JSON response. And ads resource URLs are not easily distinguishable from real content.
Correct, because first-party / third-party is not a technical difference, but a social/commercial one. The app.example.com may run in a different cloud and be part of the same first-party service.
AFAIK, cloudflare only flattens CNAMEs at the root level, and that’s because CNAMEs at the root are not a standard. They have to convert it to an A record to be standards compliant.
Cloudflare nameservers also flatten CNAMEs pointing to workers.dev (a domain they own), for example.
My intention was to point out that nameservers that flatten CNAMEs render DNS-based blocking ineffective.
DNSCrypt-proxy (and even pihole these days I believe) are actually capable of blocking forwarded CNAME requests. Setting up such system for network wide adblocking is not complicated at all, see: https://github.com/notracking/hosts-blocklists/wiki/Install-...
“Other tracking countermeasures operate as a DNS resolver, and return a bogus IP address, e.g. 127.0.0.1 when the domain name matches an entry from the blocklist. As this defense works at the DNS level, these can also consider all the intermediary resolutions to CNAME records, and return a bogus IP address if any of them resolve to a domain on the blocklist. Examples of DNS-based anti-tracking measures that adopted defenses against CNAME cloaking include NextDNS [42], AdGuard [4], and Pi-hole [50].”
It’s worth reading NextDNS’s discussion on how this is implemented, and the differences between their approach, AdGuard’s, and pihole’s:
https://medium.com/nextdns/nextdns-added-cname-uncloaking-su...
If you have NextDNS configured with the AdGuard base filter set, www.cultofmac.com is blocked for being CNAMED to www-cultofmac-com.ezoic.net which in turn is blocked by the AdGuard base filter. In this case, ezoic is an ad-optimizing content management system (CMS).
Here’s a wiki for setup for most routers, see Supported Platforms at the bottom:
Wiki: https://github.com/nextdns/nextdns/wiki
Splash page: https://nextdns.io/
Setup: https://my.nextdns.io/start
For iOS families, NextDNS now supports Apple Configuration Profiles to enforce Encrypted DNS at the policy level, no software to install or manual settings: https://apple.nextdns.io/
And if your IP is dynamic, it supports reversing that public IP from a dynamic hostname service.
The only way to stop this permanently is to address the root cause. As far as I can tell that would be through permissioned browser api access. The UX might become a bit unwieldy though Google’s idea of limiting the number of bits of identifying info revealed might be a way around that.
But then there is the issue of sites blocking access when more bits of identity are not given. This would lead to another cat and mouse game of tricking sites into thinking they are getting globally useful identity bits and the sites trying to counter this. This might be an easier game to play for the users where they randomly generate and isolate this data per domain or container but I’m not sure.
hm? So the Trick of Computerpeople is simple and knowingly to block requests to prevent abuse ?
That reminds me, of the arrogant young, wanting to compete boasting at 'social' -media, keeping -critics-(crossed) 'hater' away and small, while advertising (in self-interest) for so called 'social'-media to selfish gain their own position (on 'social'-media) ?!
Heading: 'Inclusion' -so 'This 'generate and isolate' might be an easier game to play for this users' ?
'Everytime everything must be positive, not ?'
Now that was realy OT...Sry! Won't sound too offensive.. P-:
But from your first sentence I gather you think my comment is trying to justify the current business practices of ad driven tech companies. It is not. I fundamentally disagree with that revenue model, at least how it primarily exists today, for many reasons.
One can work at changing the system which allows such business models to exist but typically that is much harder than working within the system to mitigate some of its effects on the individual. Working to change the system typically has much wider effects while working within the system typically has much narrower effects (one must opt in) and as such some or many may be left out.
My comment is about what one pragmatically might do when working within the system.
The security aspect is valid too, though I'm not sure if it's much worse than allowing a third party to put arbitrary Javascript on your website in the first place (as almost none of the trackers support integrity tags or self-hosting of analytics scripts). Of course those scripts don't get access to HTTPOnly cookies, which the server API will get when using such a CNAME script.
A solution would be to have your website on a subdomain itself (e.g. www), which was best practice for a while but got abandoned for the sake of brevity with most sites.
That's because you're confusing tracking, which is e.g. Google tracking your behaviour across different websites to decide what you like and what adds you might click, and website analytics, which is making statistics on what type of people ( location, language, browser, mobile/PC, from where) visit your website. Privacy concious analytics doesn't track it, it only aggregates who you are so that the website owner can make decisions ( the mobile version is useless because all users come from PCs, optimising for Safari isn't needed since no users use Apple devices, etc.). It's unfortunate for your average site owner that you lose that data from people not wanting to be tracked, because that's really not the same thing, they're just a drive-by casualty.
Indeed, I just looked at the source code, and since MaraDNS uses a hash to look up rogue IPs, this list can be arbitrary long with only memory usage going up. Because these kinds of rogue IPs are (were) rare, there is a hard-coded limit of 1,000 IPs in the source code, but that’s a one-line patch to increase to 10,000 or even 100,000 max bad IPs.
The syntax in one’s dwood3rc file to have this feature is this:
ip_blocklist="10.6.6.6, 10.1.2.3, 10.5.4.3"
ip_blocklist+=", 10.6.0.6, 10.1.6.9"
The only one I know is crimeflare [1] but it's specific to cloudflare proxied malicious websites. It would be awesome to have a similar directory for second-party domains that point to known ad service IP ranges.
[1] http://www.crimeflare.org on port 82
Also, fighting back against ... what exactly? Ads? The Big FAANG?
This is not the way. It's either beat them at their game (not likely), or building/supporting/using alternatives (eg. Signal, Mastodon, maybe substack? nebula? Librem/microG/LineageOS?), but ultimately it's politics. If "HN thinks" they are too powerful, then "HN has to" influence and persuade people in order to get laws, policies, regulations enacted that control/diminish this power. (Of course if such a grassroots movement gets powerful enough to influence legislation/policy probably at that point the market would respond too, eg. maybe Google would offer a no-track version of their services for cash, or serious competitors would emerge.)
The cynical take is of course a simple good luck, after all "HN" doesn't even have to fortitude to ditch Chrome.
(I hate ads with a passion, and use uBlock, but I don't care about tracking. Sites can and will implement it in their own backend anyway. GDPR/CCPA is the correct level to address the real problem which is handling of personal data [not IP address]. Now it's up to the market and consumer/user behavior to adjust. All these obnoxious consent forms are ripe for "disruption", yet it seems the economic/market value of not being tracked is so low, that it's hard to build a business on it. Though NextDNS is trying, but it's such a small niche, and basically solves nothing ... still, I wish them luck.
If the policy changes regarding "news" in UK/Germany/Australia were not due to bullheaded Murdoch/NewsCorp and regular old media/publishers lobbying, then that issue could be a starting point on which to build something better. But ultimately if every simple view has to be compensated, it has to be tracked.)
Personal data harvesting. Its like feeding frenzy right now.
> This is not the way. It's either beat them at their game (not likely), or building/supporting/using alternatives (eg. Signal, Mastodon, maybe substack? nebula? Librem/microG/LineageOS?), but ultimately it's politics.
This is the way lol. Beating them is the only way that actually works, right now. Politics will takes decades, and will lead nowhere, like stupid cookies consent popups. Networking and web tech is too complex to put it into laws anyway.
Lets build better personal defence tools, browsers, routers, blockers, distributed VPNs that are not as easy to outlaw as Tor exit nodes. For example - https://github.com/Eloston/ungoogled-chromium. Add ignoramous CNAME backdooring ways to uBlock-Origin. That kind of ways.
There's no need to put tech into laws. The law is about privacy and consent. Do not call/spam/contact me without my consent, and don't even store/put my contact into a database without my consent. ( https://en.wikipedia.org/wiki/Nothing_About_Us_Without_Us )
Sure, the next step is culling those mindless consent popups.
> Politics will takes decades [...]
It's the only way that really works. Informing people and building a movement.
Otherwise just hiding in the noise makes no real difference to our lives. (Because our friends, family, neighbors, coworkers, etc. will be still tracked, targeted, etc. They won't setup a piHole.)
I see. You underestimate or don't think that tracking today is the issue. Whats leaked cannot be unleaked. So far big tech only uses it for ads. Tomorrow it'll use it for banking, insurance, job applicants assessments, like Social Credit System in China today. Data sources are enormous, movement, friends, calls, chats, emails, purchases, searches and so on. "Person googles for drinking problems periodically since 2014."
So when it does become an issue in real life, it'll be too late, all data is already collected and processed into profiles.
And not only our data. Every school kid with Chromebook and Google account.
PS: Did you see this episode? If not, its my favourite, fun and scary at same time :)) https://en.wikipedia.org/wiki/Nosedive_(Black_Mirror)
Basically my view is that we urgently need to focus on the real world outcomes, what GDPR actually did. Consent about any storing and processing, so consequences all the way up and down the chain. Data controller, processor(s) and sub-processor(s), and so on.
The technology of data-drivenness is here to stay. Businesses will use it. Consumers will consent to almost anything for a few cents of discount. And that's the next problem. So it'd be great to simply make a few basic marketing data techniques opt-out and very much make the rest require a review/permit from some authority.
----
That said I don't have much to compare "tracking today" against or with. I don't like advertisements in any form. (Billboards, TV/radio/podcast/youtube ads, native or not. Targeted or not.)
Also there are already profiles, databases, and they would be without adtech too. (Just look at China, there is no Google, but they have a surveillance state. Sure, baidu/qq/tencent/alibaba are all having their adtech, and probably the central government have access to whatever they want.)
Big tech or not, there are already fewer protected classes (in labor law) than there should be. Plus if an employer wants to fire someone, they will find some bullshit reason anyway.
Similarly, banks already require a lot of data, a signed paper to verify employment, past transaction history, and there's the whole positive-negative credit score. (And people gladly give consent to receive a small fractional percentage better interest.)
You are likely aware that many non-protected data categories correlate very highly with the protected ones. This puts many people at a disadvantage. (Yet at the same time not everyone has the same income, so not everyone has the same ability to service a loan. Of course the problem is very deep, because we know that the huge income inequality is also very much not because some of us happens to value income a lot more than free time, while some of us value free time more than income, which would lead to a "natural income inequality distribution".)
Tech (big or not) is simply manifesting deep(er) problems. Sure, this is not a reason to not regulate tech. (Quite the contrary.) But I still think keeping things in perspective is important.
Are you saying an IP isn't / can't be personal data or am I misunderstanding the sentence?
It could becomes PII or personal data if that same IP then gets correlated to name, address, birth date, etc.
I'm aware that the GDPR for example considers anything personal data that is "related" to an identifiable natural person, but cookies and IP addresses can only become that "indirectly" if someone watches you and your network traffic. (Or retroactively, if someone with that IP and session cookie provides more information during that session.)
Essentially I argue that in a system that doesn't do profiling, doesn't even have the ability to ask for more personal data (eg. name), cannot link IP to a person. So in that system IP address is not personal data.