9 ms·

The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion

115 points by spenvo 6y ago

spenvo 6y ago
CNAME-tracking is a relatively new phenomenon, where ad marketing firms (led by Salesforce and Adobe) are convincing sites to tweak CNAME records in order to get browsers to send a domain's cookie data (yes, security implications here are severe). This tracking method has become increasingly popular with tens of thousands of high-traffic sites utilizing it, and browsers have no built-in defenses against it. A more at-length layman's explanation can be found here, starting on page 8 https://www.grc.com/sn/sn-808-notes.pdf https://www.grc.com/sn/sn-808-notes.pdf But as the title hits upon, there is one countermeasure that uBlock Origin has implemented for its Firefox extension. But unlike Firefox, Chrome does not provide robust enough extension APIs for the countermeasure to work there. Chrome users are currently completely susceptible to having private cookie data stolen on thousands of high-traffic sites. Even in the case of this countermeasure though, it does seem insufficient as it's essentially a whack-a-mole game. Browsers must prioritize shutting this down in a more foolproof way, and I can't imagine an easy way to do that.
- thrwwy0304 6y ago
  This is false. Safari and Firefox both have strong third party cookie protections that prevent linking identities across different sites. At this point, the only way an ad network can tell that the same user is on Website A and Website B is if both site owners tell the ad network the current user's email address or other common identifier. If both sites are opting into this, CNAME protections won't do anything.
  - thrwwy0304 6y ago
    The cookie protections I'm referencing are Safari's "Intelligent Tracking Protection" and Firefox's "Total Cookie Protection." Efforts would be much better spent trying to stop fingerprinting, trying to convince Chrome to add third party cookie protection, or lobbying for regulation.
    - rodgerd 6y ago
      The third of those. This isn't a technical problem, it's a "greedy maw of the surveillance economy" problem.
  - donmcronald 6y ago
    The CNAMEs change it to a same site / first party relationship. It says it right in the article summary. I assume the way it works is that instead of `tracking.example.com` where everyone can block `example.com`, they have users set up CNAMEs instead. So you get: - extras.example.net --> tracking company IP behind a huge CDN - awesone.example.org --> tracking company IP behind a huge CDN The sites are different, but when you visit them you're hitting the tracking servers who get to see you hit both sites. Even worse, they can set cookies on the the domain, which is why someone else said there are security implications. I've been saying it for years. Eventually everything will appear to be first party and hitting huge CDN IPs. It's easy to do right now already. Go read the Cloudflare blog article on proxying Google Fonts via Workers. Then think about the Cloudflare Apps and how easy it would be to build an app that rotated first party CNAMES and used Workers to dynamically rewrite HTML to proxy the tracking to ad companies. TLDR; We're super screwed.
    - thrwwy0304 6y ago
      We're not super screwed. extras.example.net is still third-party to awesome.example.org. The tracking company has no way of knowing that an HTTP request to extras.example.net is from the same user as an HTTP request to awesome.example.org. If you were operating the tracking company, how would you try to determine the same user is behind both requests? Happy to be proven wrong, but I don't believe it's possible with third-party cookie protections in place.
      - fluidcruft 6y ago
        Based on reading the links someone posted, my understanding is that the way this CNAME stuff works is: 1. awesome.example.org would add a CNAME record that resolves tracking-you.example.org to the server referenced by evil.com 2. awesome.other.net would add a CNAME record that resolves tracking-you.other.net to the server referenced by evil.com 3. etc everywhere on the internet Because these are CNAME, DNS hides all of this from the browser and it just sees the resolved address and the original requested name. So tracking-you.example.org and tracking-you.other.net both now think the server controlled by evil.com is first-party. evil.com now gets all the first-party cookies. In the past they would have only got third-party cookies and the first-party cookies wouldn't be seen by evil.com. But it gets worse because evil.com is also tracking you (it's what they're explicitly doing) so they can link users across the sites. This means evil.com has all it needs to spoof you cross-site because they now have all the first-party auth tokens. Unless you diligently never use the sites simultaneously and remember to log out between using websites. But even if you did, they can still do anything they want as you while you're logged in to the site. So, yeah. It actually looks like a disaster and we're super screwed.
  - jrochkind1 6y ago
    You are talking about the rules for javascript access to cookies, or other rules for "cross-domain cookies". The rules for "block third-party cookies" features are different than these, and are browser-specific rather than bound by a standard. I believe that both Chrome and Firefox will not block cookies from a subdomain of the same base domain as "third-party". Although I'm not totally sure where to find this documented. I think if they did, it would break many more sites than "block third-party cookies" do now.
    - thrwwy0304 6y ago
      The way tracking used to work is: 1. UserA visits foo.com which embeds a script from evil.com. When the script is requested, evil.com sees there's no tracking cookie for this user yet, so it drops one. 2. When evil.com was loaded, the Referer header showed the request was coming from foo.com. EvilCo adds an entry that UserA visited foo.com. 3. UserA now visits bar.com which also embeds a script from evil.com. Now, the tracking cookie from Step 1 already exists, so it's sent with the request to load the script from evil.com. 4. evil.com looks at the Cookie and Referer header, and adds an entry that UserA has visited bar.com. --- Now, what Firefox and Safari have done, is they've made it impossible for ANY third party to access their cookies while a user is visiting a different site. I completely understand that evil.com is promoting itself to first-party by routing under evil.foo.com and evil.bar.com, and that allows it to set and receive cookies on those hosts, but that alone isn't enough to break out of the new browser protections. In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. To sync identities across evil.foo.com and evil.bar.com, EvilCo is forced to do some kind of browser fingerprinting, or to rely on the operators of foo.com and bar.com to manually share additional data about the user. --- Source - I've tried it! Run two separate domains and see if you can get the same unique identifier in cookies on both domains. The only workarounds are OAuth2 and the Storage Access API - both of which require explicit user permission.
      - jrochkind1 6y ago
        Thanks for trying to explain. What I'm not following is that you say: > In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. But in your original 1-4 description, foo.com and evil.com already were third-party to each other. So apparenty that was not a barrier? Your original description doesn't actually mention mention any shared identifiers between evil.com and foo.com, just that evil.com would use a referer header to see that the rquest was coming from foo.com. Won't this work exactly the same way with evil.foo.com and evil.bar.com? Your original 1-4 stopped working because FF and Chrome stopped letting evil.com set cookies at all when loaded from foo.com. That is the restriction that broke 1-4 (it wasn't other restrictions that were in place when 1-4 was working fine), and that is the restriction you get around with evil.foo.com, restoring the situation where your 1-4 steps worked. What am I missing?
- jaytaylor 6y ago
  Appreciate you raising awareness about this! Seems like one more nail in the coffin for Chrome versus alternatives which have a higher degree of people's true best interests at heart. As a side note, this really deserves a blog post or singular site/page that explains the issue in a simple enough way so the word can spread.
  - random5634 6y ago
    Another nail? I’ve been hearing that for 10 years - be interesting to see if chrome usage drops a lot. With edge now chromium based I’ve been seeing usage go up not down
    - shawnz 6y ago
      Anecdotally, I switched to FF after the manifest v3 changes were announced.
      - croes 6y ago
        Chrome is the new IE. Everybody knows it's bad, but it's standard.
        minikites 6y ago
        Except web developers love Chrome, which is why Google might actually win control of the web.
        jimbob45 6y ago
        Amen. FF’s dev tools are like Windows 95 to Chrome’s Windows 7.
        temp667 6y ago
        Yeah, from where I sit Chrome is the absolute first target, regardless of how many nails are being nailed into its coffin. There is some thought that if Apple opens up iOS a bit Chrome could make more headway there as well. Numbers I've heard are Chrome - 60%, Firefox < 5%.
- dang 6y ago
  The submitted title ("CNAME tracking's a disaster. uBlock Origin blocks it in FF. Chrome users are SOL") broke the site guidelines. Accounts that do that eventually lose submission privileges, so please don't do that. It looks like a fine submission otherwise! "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - spenvo 6y ago
    Thanks dang, sorry—I blanked out on that rule and will try to remember moving forward (I think I’ve made this mistake before). Cheers
    - dang 6y ago
      Appreciated!
- tinus_hn 6y ago
  How can browsers defend against sites giving away their own private cookies to trackers? They could just as well send the data from the server side.
- XzetaU8 6y ago
  "Chrome users are currently completely susceptible to having private cookie data stolen on thousands of high-traffic sites" Not true, sure it's a workaround solution but with frogeye's block list [0] and uBO you're pretty much covered on Chrome regarding CNAME-tracking [0]:Geoffrey Frogeye's block list of first-party trackers https://hostfiles.frogeye.fr/ https://hostfiles.frogeye.fr/
Spivak 6y ago
Outside of the fact that sites would be mad is there a problem is browsers just chase cnames and set the origin to the last one? Yes sites could switch to A records or proxies but that's way more of a PITA on the tracker side.
- cjm42 6y ago
  Yes, it would cause issues with hosting services that use CNAMES in the way they were intended. e.g www.example.com might be CNAMEd to example.bigwebhost.com so that bigwebhost can change the IP addresses used by example.com without having access to example.com's DNS. Your proposed change would make every site hosted by bigwebhost part of the same domain, potentially leaking cookies to each other.
  - lazulicurio 6y ago
    You could do something similar to how FF implemented their new cookie isolation. Make the key (original domain ^ final CNAME). Which probably would still have issues, but I think it's worth looking into.
anfilt 6y ago
using a CNAME to allow third party trackers seems like a horrible idea... You risking exposing cookies and other sensitives data to some third party... I guess these sites don't care.
- gruez 6y ago
  It's not any worse than third party scripts, which give you full access to the DOM.
  - colinclerk 6y ago
    It's a different attack vector. Session tokens should be stored in an httpOnly cookie, so they're not accessible to a third party script. CNAMEs could absolutely lead to leaked session tokens, but website owners should already be somewhat accustomed to hiding cookies away from third party subdomains. These days, lots of third party services run on subdomains... blogs, status pages, email click trackers, support desks, etc.
    - gruez 6y ago
      >Session tokens should be stored in an httpOnly cookie, so they're not accessible to a third party script. You can't steal cookies, but you can perform actions as the user, eg. $.post("/api/transfer_funds", {"recipient": "attacker", "amount": 999999})
c7DJTLrn 6y ago
So tired of this arms race. The Web is an absolute joke.
- zaik 6y ago
  So... Gemini?
- airstrike 6y ago
  Bring back geocities! No, really
tyingq 6y ago
"That will kill any ability to use heuristics for blocking" was a pretty common response to Google's Manifest V3 stuff. They knew this was coming.
- 0xy 6y ago
  Manifest V3 was always a massive advertiser land grab. Their intent is to kill effective ad blockers and replace them with ad blockers on the payroll ("acceptable" ads) or nothing at all. Gorhill told the Chrome team that this would effectively kill ad blocking. He was ignored (are you surprised?).
ballenf 6y ago
From the full-text article: > visits to different websites cannot be attributed to the same user using standard web development features. This was stated in a section about the limitations of CNAME tracking. Maybe the article mentions this later, but wouldn't a single call from the web server to the ad server negate this limitation? That is cross-site tracking is simply a matter of running a little more ad tracker code in your server.
- beagle3 6y ago
  You need more cooperation from the domains that do the CNAME cloaking. In fact, the CNAME just makes it a little easier to deploy - The domain server could -- on the backend, without you having any idea or way to intervene -- notify TrackerCompany that "I now see user xyz who registered with email abc@def.com first name "john" last name "smith" claiming to be 43; he is coming from ip i.j.k.l and is browsing /blah/widget/plan.html, a page about widgets" But the site owners don't trust the TrackerCompany with this much information. And the TrackerCompany doesn't trust site owners to be honest (they have an incentive to provide false/inflated data). They started eith 3rd party scripts and cookies, which was a middle ground (site owners have to work harder to lie and must leave some trail if they do; trackercompany must introduce malicious javascript if they want more than was agreed upon). Browsers are making this unusable, so it's shifting to CNAME - website owners have to do a little more work, and have to trust trackercompany more; In the trust/power balance, the sites lose power and give trust (both of which go to trackercompany). But they haven't noticed yet. So, you are absolutely right, it's just a matter of trust and convenience, which is being shifted - but ultimately, all it takes is just one call from the backend server to undo all privacy protections.
baal80spam 6y ago
Strange, I don't see this option in my uBlock for FF.
- tyingq 6y ago
  I don't think it's a visible option. It just uncloaks CNAMES so that putting those domains on the block list works. It does highlight them in blue. See here: https://github.com/gorhill/uBlock/releases/tag/1.25.0 https://github.com/gorhill/uBlock/releases/tag/1.25.0
- gorhill 6y ago
  It's enabled by default since 1.25.0, but it can be disabled or fine-tuned through advanced settings.[1] In next release, the option is moved from advanced settings to normal user settings, i.e. it will become visible in the Settings pane of uBO's dashboard.[2] --- [1] https://github.com/gorhill/uBlock/wiki/Advanced-settings#cnameuncloak https://github.com/gorhill/uBlock/wiki/Advanced-settings#cna... [2] https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#uncloak-canonical-names https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...
jedisct1 6y ago
`dnscrypt-proxy` blocks these, as well as the SVCB and HTTPS variants.
WarOnPrivacy 6y ago
Chrome's crippling of uBO's protections are what drove me away, once and for all. In this case, me means my household and customer base. I setup everyone on Firefox for their protection. Most stick with it. Some vendors request FF. Lightspeed is one.
roylez 6y ago
Just updated my AdguardHome's block list. Non tech savvy people are screwed. Honestly, how could the majority win this game even when people surfing HN are scrambling to catch up?
blitz_skull 6y ago
Aaaaaaaand, I'm now reading this from FF. Google needs to get its shit together.
mixedCase 6y ago
Interesting. I'm hoping Brave fixes it downstream, it's the kind of thing they can use to prove themselves as the privacy-oriented Chromium fork.
- alibert 6y ago
  It's already included in the native adblocker in Brave (oct 2020) https://brave.com/privacy-updates-6/ https://brave.com/privacy-updates-6/ Edit: not exactly bringing the feature to extension but people usually use Brave Shield + uBlock.
yayr 6y ago
The real problem with CNAME-tracking is that it provides the loaded adtech libraries the security privileges from the hosted domain. This means, tracking libs can now also access everything of the website they are hosted in, attach any event handlers etc. It is essentially the same as hosting the tracking library from the content server, except that the tracking provider can change the source code anytime without requiring any consent. This is a security nightmare imo.
- temp667 6y ago
  One asked for by folks on HN who said third party cookies should be blocked - well, the ad tech companies are making them first party. I'm surprised they even setup another domain, you could do path rewriting at load balancer level to route the /extras path to the ad tech software / provider.
  - deleted 6y ago
    [deleted]
  - JdeBP 6y ago
    The advertisement providers do not trust the content providers not to generate fake page fetches. This rules out any sort of mechanism where the advertisement providers trust reverse proxies or any other sort of request relaying on the content providers' parts.
- tinus_hn 6y ago
  Not much more of a security nightmare than loading Javascript from a random ad server, really. I think the main point is just to make it harder to block using pi-hole like solutions.
- Natsu 6y ago
  This makes me dream of making social media decentralized again. If there were some way to make it peer-to-peer so that it didn't require running servers and yet some way to make it so that visibility is reduced to only your actual connections or maybe sometimes one degree from your immediate connections so that you could get introductions from others and explicitly made impossible thereby to spider or otherwise hoover up all the data by any party, effectively making it part of the 'dark' web. So if you want to search it should be the small dataset from your own connections and local to you. At least that's the vision, to make the web "smaller" again like it was before Eternal September, and to create some protocol implementing a vision like that to take over and wrest things from giant oligarchs controlling all social media. I have no idea if making that is even feasible, though I've seen some attempts vaguely similar to that. I see tons of practical challenges with actually implementing such a thing, though, but the idea would be to make all the communication opaque and explicitly take it away from harvesters. Granted, there's no way that could end things... I'm sure clients might get subverted via various methods to re-enable harvesting but at least it would limit their scope and you could remove such folks as connections if you knew.
AuthorizedCust 6y ago
The next step will be to proxy the 3rd party site. For example, if you run www.example.com, you set up tracker.example.com pointing to your own web server. You configure your web server to proxy tracker.ad_tech_company.com. As long as tracker.ad_tech_company.com is smart enough not to give away that it's not part of example.com, there's no way for one's browser to notice this. tracker.example.com is not a cname, and it will almost certainly refer to an IP that is within your corporation's or host's IP space. This is minimal complexity. It's not a ton of bandwidth if it's mainly cookies. Similar is to use use the engagement tools inside your own web content management system. The majors (Adobe AEM, Sitecore, etc.) are already offering it.
- zeroimpl 6y ago
  The ad company isn't going to trust any data which is routed through the backend of your web server. Otherwise spoofing page views/clicks is trivial. The next step is to get a CDN to proxy both www.example.com and tracker.example.com and promise to be independent, or for the ad company to operate the proxy themselves.
upofadown 6y ago
The web sites in question can make their subdomains point anywhere they want. They can forward all their tracking info to the ad companies without any real technical innovation. This fight is ultimately futile. The only real solution here is legislative. BTW, why do browsers not treat subdomains as separate entities for the purposes of figuring out what is a third party? Why don't they restrict things on the basis of IP addresses and skip all this complexity? One connection, one IP address...
dang 6y ago
Related threads, for those interested. Are there others? AdGuard publishes a list of 6K+ trackers abusing the CNAME cloaking technique - https://news.ycombinator.com/item?id=26349857 https://news.ycombinator.com/item?id=26349857 - March 2021 (49 comments) Cname / DNS based third party tracking - https://news.ycombinator.com/item?id=26297984 https://news.ycombinator.com/item?id=26297984 - Feb 2021 (46 comments) Plausible Analytics Isn't GDPR Compliant - https://news.ycombinator.com/item?id=24868012 https://news.ycombinator.com/item?id=24868012 - Oct 2020 (75 comments) uBlock Origin 1.25.0 uncloaks CNAME-masked network requests in Firefox - https://news.ycombinator.com/item?id=22404808 https://news.ycombinator.com/item?id=22404808 - Feb 2020 (4 comments) NextDNS first to block ALL third-party trackers disguised as first-party - https://news.ycombinator.com/item?id=21610386 https://news.ycombinator.com/item?id=21610386 - Nov 2019 (4 comments) Cname cloaking, a disguise of third-party trackers - https://news.ycombinator.com/item?id=21604825 https://news.ycombinator.com/item?id=21604825 - Nov 2019 (196 comments)
pacman2 6y ago
Stupid question: Can I block this with a host file? I know Adguard published a list. Kudos to them, but can this be used in an extensive host file? https://github.com/AdguardTeam/AdGuardFilters https://github.com/AdguardTeam/AdGuardFilters

115 points by spenvo 6y ago

CNAME-tracking is a relatively new phenomenon, where ad marketing firms (led by Salesforce and Adobe) are convincing sites to tweak CNAME records in order to get browsers to send a domain's cookie data (yes, security implications here are severe). This tracking method has become increasingly popular with tens of thousands of high-traffic sites utilizing it, and browsers have no built-in defenses against it. A more at-length layman's explanation can be found here, starting on page 8 https://www.grc.com/sn/sn-808-notes.pdf https://www.grc.com/sn/sn-808-notes.pdf But as the title hits upon, there is one countermeasure that uBlock Origin has implemented for its Firefox extension. But unlike Firefox, Chrome does not provide robust enough extension APIs for the countermeasure to work there. Chrome users are currently completely susceptible to having private cookie data stolen on thousands of high-traffic sites. Even in the case of this countermeasure though, it does seem insufficient as it's essentially a whack-a-mole game. Browsers must prioritize shutting this down in a more foolproof way, and I can't imagine an easy way to do that.

thrwwy0304 6y ago
This is false. Safari and Firefox both have strong third party cookie protections that prevent linking identities across different sites. At this point, the only way an ad network can tell that the same user is on Website A and Website B is if both site owners tell the ad network the current user's email address or other common identifier. If both sites are opting into this, CNAME protections won't do anything.
- thrwwy0304 6y ago
  The cookie protections I'm referencing are Safari's "Intelligent Tracking Protection" and Firefox's "Total Cookie Protection." Efforts would be much better spent trying to stop fingerprinting, trying to convince Chrome to add third party cookie protection, or lobbying for regulation.
  - rodgerd 6y ago
    The third of those. This isn't a technical problem, it's a "greedy maw of the surveillance economy" problem.
- donmcronald 6y ago
  The CNAMEs change it to a same site / first party relationship. It says it right in the article summary. I assume the way it works is that instead of `tracking.example.com` where everyone can block `example.com`, they have users set up CNAMEs instead. So you get: - extras.example.net --> tracking company IP behind a huge CDN - awesone.example.org --> tracking company IP behind a huge CDN The sites are different, but when you visit them you're hitting the tracking servers who get to see you hit both sites. Even worse, they can set cookies on the the domain, which is why someone else said there are security implications. I've been saying it for years. Eventually everything will appear to be first party and hitting huge CDN IPs. It's easy to do right now already. Go read the Cloudflare blog article on proxying Google Fonts via Workers. Then think about the Cloudflare Apps and how easy it would be to build an app that rotated first party CNAMES and used Workers to dynamically rewrite HTML to proxy the tracking to ad companies. TLDR; We're super screwed.
  - thrwwy0304 6y ago
    We're not super screwed. extras.example.net is still third-party to awesome.example.org. The tracking company has no way of knowing that an HTTP request to extras.example.net is from the same user as an HTTP request to awesome.example.org. If you were operating the tracking company, how would you try to determine the same user is behind both requests? Happy to be proven wrong, but I don't believe it's possible with third-party cookie protections in place.
    - fluidcruft 6y ago
      Based on reading the links someone posted, my understanding is that the way this CNAME stuff works is: 1. awesome.example.org would add a CNAME record that resolves tracking-you.example.org to the server referenced by evil.com 2. awesome.other.net would add a CNAME record that resolves tracking-you.other.net to the server referenced by evil.com 3. etc everywhere on the internet Because these are CNAME, DNS hides all of this from the browser and it just sees the resolved address and the original requested name. So tracking-you.example.org and tracking-you.other.net both now think the server controlled by evil.com is first-party. evil.com now gets all the first-party cookies. In the past they would have only got third-party cookies and the first-party cookies wouldn't be seen by evil.com. But it gets worse because evil.com is also tracking you (it's what they're explicitly doing) so they can link users across the sites. This means evil.com has all it needs to spoof you cross-site because they now have all the first-party auth tokens. Unless you diligently never use the sites simultaneously and remember to log out between using websites. But even if you did, they can still do anything they want as you while you're logged in to the site. So, yeah. It actually looks like a disaster and we're super screwed.
- jrochkind1 6y ago
  You are talking about the rules for javascript access to cookies, or other rules for "cross-domain cookies". The rules for "block third-party cookies" features are different than these, and are browser-specific rather than bound by a standard. I believe that both Chrome and Firefox will not block cookies from a subdomain of the same base domain as "third-party". Although I'm not totally sure where to find this documented. I think if they did, it would break many more sites than "block third-party cookies" do now.
  - thrwwy0304 6y ago
    The way tracking used to work is: 1. UserA visits foo.com which embeds a script from evil.com. When the script is requested, evil.com sees there's no tracking cookie for this user yet, so it drops one. 2. When evil.com was loaded, the Referer header showed the request was coming from foo.com. EvilCo adds an entry that UserA visited foo.com. 3. UserA now visits bar.com which also embeds a script from evil.com. Now, the tracking cookie from Step 1 already exists, so it's sent with the request to load the script from evil.com. 4. evil.com looks at the Cookie and Referer header, and adds an entry that UserA has visited bar.com. --- Now, what Firefox and Safari have done, is they've made it impossible for ANY third party to access their cookies while a user is visiting a different site. I completely understand that evil.com is promoting itself to first-party by routing under evil.foo.com and evil.bar.com, and that allows it to set and receive cookies on those hosts, but that alone isn't enough to break out of the new browser protections. In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. To sync identities across evil.foo.com and evil.bar.com, EvilCo is forced to do some kind of browser fingerprinting, or to rely on the operators of foo.com and bar.com to manually share additional data about the user. --- Source - I've tried it! Run two separate domains and see if you can get the same unique identifier in cookies on both domains. The only workarounds are OAuth2 and the Storage Access API - both of which require explicit user permission.
    - jrochkind1 6y ago
      Thanks for trying to explain. What I'm not following is that you say: > In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. But in your original 1-4 description, foo.com and evil.com already were third-party to each other. So apparenty that was not a barrier? Your original description doesn't actually mention mention any shared identifiers between evil.com and foo.com, just that evil.com would use a referer header to see that the rquest was coming from foo.com. Won't this work exactly the same way with evil.foo.com and evil.bar.com? Your original 1-4 stopped working because FF and Chrome stopped letting evil.com set cookies at all when loaded from foo.com. That is the restriction that broke 1-4 (it wasn't other restrictions that were in place when 1-4 was working fine), and that is the restriction you get around with evil.foo.com, restoring the situation where your 1-4 steps worked. What am I missing?
jaytaylor 6y ago
Appreciate you raising awareness about this! Seems like one more nail in the coffin for Chrome versus alternatives which have a higher degree of people's true best interests at heart. As a side note, this really deserves a blog post or singular site/page that explains the issue in a simple enough way so the word can spread.
- random5634 6y ago
  Another nail? I’ve been hearing that for 10 years - be interesting to see if chrome usage drops a lot. With edge now chromium based I’ve been seeing usage go up not down
  - shawnz 6y ago
    Anecdotally, I switched to FF after the manifest v3 changes were announced.
    - croes 6y ago
      Chrome is the new IE. Everybody knows it's bad, but it's standard.
      - minikites 6y ago
        Except web developers love Chrome, which is why Google might actually win control of the web.
        jimbob45 6y ago
        Amen. FF’s dev tools are like Windows 95 to Chrome’s Windows 7.
        temp667 6y ago
        Yeah, from where I sit Chrome is the absolute first target, regardless of how many nails are being nailed into its coffin. There is some thought that if Apple opens up iOS a bit Chrome could make more headway there as well. Numbers I've heard are Chrome - 60%, Firefox < 5%.
dang 6y ago
The submitted title ("CNAME tracking's a disaster. uBlock Origin blocks it in FF. Chrome users are SOL") broke the site guidelines. Accounts that do that eventually lose submission privileges, so please don't do that. It looks like a fine submission otherwise! "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- spenvo 6y ago
  Thanks dang, sorry—I blanked out on that rule and will try to remember moving forward (I think I’ve made this mistake before). Cheers
  - dang 6y ago
    Appreciated!
tinus_hn 6y ago
How can browsers defend against sites giving away their own private cookies to trackers? They could just as well send the data from the server side.
XzetaU8 6y ago
"Chrome users are currently completely susceptible to having private cookie data stolen on thousands of high-traffic sites" Not true, sure it's a workaround solution but with frogeye's block list [0] and uBO you're pretty much covered on Chrome regarding CNAME-tracking [0]:Geoffrey Frogeye's block list of first-party trackers https://hostfiles.frogeye.fr/ https://hostfiles.frogeye.fr/

Spivak 6y ago

Outside of the fact that sites would be mad is there a problem is browsers just chase cnames and set the origin to the last one? Yes sites could switch to A records or proxies but that's way more of a PITA on the tracker side.

cjm42 6y ago
Yes, it would cause issues with hosting services that use CNAMES in the way they were intended. e.g www.example.com might be CNAMEd to example.bigwebhost.com so that bigwebhost can change the IP addresses used by example.com without having access to example.com's DNS. Your proposed change would make every site hosted by bigwebhost part of the same domain, potentially leaking cookies to each other.
- lazulicurio 6y ago
  You could do something similar to how FF implemented their new cookie isolation. Make the key (original domain ^ final CNAME). Which probably would still have issues, but I think it's worth looking into.

anfilt 6y ago

using a CNAME to allow third party trackers seems like a horrible idea... You risking exposing cookies and other sensitives data to some third party... I guess these sites don't care.

gruez 6y ago
It's not any worse than third party scripts, which give you full access to the DOM.
- colinclerk 6y ago
  It's a different attack vector. Session tokens should be stored in an httpOnly cookie, so they're not accessible to a third party script. CNAMEs could absolutely lead to leaked session tokens, but website owners should already be somewhat accustomed to hiding cookies away from third party subdomains. These days, lots of third party services run on subdomains... blogs, status pages, email click trackers, support desks, etc.
  - gruez 6y ago
    >Session tokens should be stored in an httpOnly cookie, so they're not accessible to a third party script. You can't steal cookies, but you can perform actions as the user, eg. $.post("/api/transfer_funds", {"recipient": "attacker", "amount": 999999})

c7DJTLrn 6y ago

So tired of this arms race. The Web is an absolute joke.

zaik 6y ago
So... Gemini?
airstrike 6y ago
Bring back geocities! No, really

tyingq 6y ago

"That will kill any ability to use heuristics for blocking" was a pretty common response to Google's Manifest V3 stuff. They knew this was coming.

0xy 6y ago
Manifest V3 was always a massive advertiser land grab. Their intent is to kill effective ad blockers and replace them with ad blockers on the payroll ("acceptable" ads) or nothing at all. Gorhill told the Chrome team that this would effectively kill ad blocking. He was ignored (are you surprised?).

ballenf 6y ago

From the full-text article: > visits to different websites cannot be attributed to the same user using standard web development features. This was stated in a section about the limitations of CNAME tracking. Maybe the article mentions this later, but wouldn't a single call from the web server to the ad server negate this limitation? That is cross-site tracking is simply a matter of running a little more ad tracker code in your server.

beagle3 6y ago
You need more cooperation from the domains that do the CNAME cloaking. In fact, the CNAME just makes it a little easier to deploy - The domain server could -- on the backend, without you having any idea or way to intervene -- notify TrackerCompany that "I now see user xyz who registered with email abc@def.com first name "john" last name "smith" claiming to be 43; he is coming from ip i.j.k.l and is browsing /blah/widget/plan.html, a page about widgets" But the site owners don't trust the TrackerCompany with this much information. And the TrackerCompany doesn't trust site owners to be honest (they have an incentive to provide false/inflated data). They started eith 3rd party scripts and cookies, which was a middle ground (site owners have to work harder to lie and must leave some trail if they do; trackercompany must introduce malicious javascript if they want more than was agreed upon). Browsers are making this unusable, so it's shifting to CNAME - website owners have to do a little more work, and have to trust trackercompany more; In the trust/power balance, the sites lose power and give trust (both of which go to trackercompany). But they haven't noticed yet. So, you are absolutely right, it's just a matter of trust and convenience, which is being shifted - but ultimately, all it takes is just one call from the backend server to undo all privacy protections.

baal80spam 6y ago

Strange, I don't see this option in my uBlock for FF.

tyingq 6y ago
I don't think it's a visible option. It just uncloaks CNAMES so that putting those domains on the block list works. It does highlight them in blue. See here: https://github.com/gorhill/uBlock/releases/tag/1.25.0 https://github.com/gorhill/uBlock/releases/tag/1.25.0
gorhill 6y ago
It's enabled by default since 1.25.0, but it can be disabled or fine-tuned through advanced settings.[1] In next release, the option is moved from advanced settings to normal user settings, i.e. it will become visible in the Settings pane of uBO's dashboard.[2] --- [1] https://github.com/gorhill/uBlock/wiki/Advanced-settings#cnameuncloak https://github.com/gorhill/uBlock/wiki/Advanced-settings#cna... [2] https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#uncloak-canonical-names https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...

jedisct1 6y ago

`dnscrypt-proxy` blocks these, as well as the SVCB and HTTPS variants.

WarOnPrivacy 6y ago

Chrome's crippling of uBO's protections are what drove me away, once and for all. In this case, me means my household and customer base. I setup everyone on Firefox for their protection. Most stick with it. Some vendors request FF. Lightspeed is one.

roylez 6y ago

Just updated my AdguardHome's block list. Non tech savvy people are screwed. Honestly, how could the majority win this game even when people surfing HN are scrambling to catch up?

blitz_skull 6y ago

Aaaaaaaand, I'm now reading this from FF. Google needs to get its shit together.

mixedCase 6y ago

Interesting. I'm hoping Brave fixes it downstream, it's the kind of thing they can use to prove themselves as the privacy-oriented Chromium fork.

alibert 6y ago
It's already included in the native adblocker in Brave (oct 2020) https://brave.com/privacy-updates-6/ https://brave.com/privacy-updates-6/ Edit: not exactly bringing the feature to extension but people usually use Brave Shield + uBlock.

yayr 6y ago

The real problem with CNAME-tracking is that it provides the loaded adtech libraries the security privileges from the hosted domain. This means, tracking libs can now also access everything of the website they are hosted in, attach any event handlers etc. It is essentially the same as hosting the tracking library from the content server, except that the tracking provider can change the source code anytime without requiring any consent. This is a security nightmare imo.

temp667 6y ago
One asked for by folks on HN who said third party cookies should be blocked - well, the ad tech companies are making them first party. I'm surprised they even setup another domain, you could do path rewriting at load balancer level to route the /extras path to the ad tech software / provider.
- deleted 6y ago
  [deleted]
- JdeBP 6y ago
  The advertisement providers do not trust the content providers not to generate fake page fetches. This rules out any sort of mechanism where the advertisement providers trust reverse proxies or any other sort of request relaying on the content providers' parts.
tinus_hn 6y ago
Not much more of a security nightmare than loading Javascript from a random ad server, really. I think the main point is just to make it harder to block using pi-hole like solutions.
Natsu 6y ago
This makes me dream of making social media decentralized again. If there were some way to make it peer-to-peer so that it didn't require running servers and yet some way to make it so that visibility is reduced to only your actual connections or maybe sometimes one degree from your immediate connections so that you could get introductions from others and explicitly made impossible thereby to spider or otherwise hoover up all the data by any party, effectively making it part of the 'dark' web. So if you want to search it should be the small dataset from your own connections and local to you. At least that's the vision, to make the web "smaller" again like it was before Eternal September, and to create some protocol implementing a vision like that to take over and wrest things from giant oligarchs controlling all social media. I have no idea if making that is even feasible, though I've seen some attempts vaguely similar to that. I see tons of practical challenges with actually implementing such a thing, though, but the idea would be to make all the communication opaque and explicitly take it away from harvesters. Granted, there's no way that could end things... I'm sure clients might get subverted via various methods to re-enable harvesting but at least it would limit their scope and you could remove such folks as connections if you knew.

AuthorizedCust 6y ago

The next step will be to proxy the 3rd party site. For example, if you run www.example.com, you set up tracker.example.com pointing to your own web server. You configure your web server to proxy tracker.ad_tech_company.com. As long as tracker.ad_tech_company.com is smart enough not to give away that it's not part of example.com, there's no way for one's browser to notice this. tracker.example.com is not a cname, and it will almost certainly refer to an IP that is within your corporation's or host's IP space. This is minimal complexity. It's not a ton of bandwidth if it's mainly cookies. Similar is to use use the engagement tools inside your own web content management system. The majors (Adobe AEM, Sitecore, etc.) are already offering it.

zeroimpl 6y ago
The ad company isn't going to trust any data which is routed through the backend of your web server. Otherwise spoofing page views/clicks is trivial. The next step is to get a CDN to proxy both www.example.com and tracker.example.com and promise to be independent, or for the ad company to operate the proxy themselves.

upofadown 6y ago

The web sites in question can make their subdomains point anywhere they want. They can forward all their tracking info to the ad companies without any real technical innovation. This fight is ultimately futile. The only real solution here is legislative. BTW, why do browsers not treat subdomains as separate entities for the purposes of figuring out what is a third party? Why don't they restrict things on the basis of IP addresses and skip all this complexity? One connection, one IP address...

dang 6y ago

Related threads, for those interested. Are there others? AdGuard publishes a list of 6K+ trackers abusing the CNAME cloaking technique - https://news.ycombinator.com/item?id=26349857 https://news.ycombinator.com/item?id=26349857 - March 2021 (49 comments) Cname / DNS based third party tracking - https://news.ycombinator.com/item?id=26297984 https://news.ycombinator.com/item?id=26297984 - Feb 2021 (46 comments) Plausible Analytics Isn't GDPR Compliant - https://news.ycombinator.com/item?id=24868012 https://news.ycombinator.com/item?id=24868012 - Oct 2020 (75 comments) uBlock Origin 1.25.0 uncloaks CNAME-masked network requests in Firefox - https://news.ycombinator.com/item?id=22404808 https://news.ycombinator.com/item?id=22404808 - Feb 2020 (4 comments) NextDNS first to block ALL third-party trackers disguised as first-party - https://news.ycombinator.com/item?id=21610386 https://news.ycombinator.com/item?id=21610386 - Nov 2019 (4 comments) Cname cloaking, a disguise of third-party trackers - https://news.ycombinator.com/item?id=21604825 https://news.ycombinator.com/item?id=21604825 - Nov 2019 (196 comments)

pacman2 6y ago

Stupid question: Can I block this with a host file? I know Adguard published a list. Kudos to them, but can this be used in an extensive host file? https://github.com/AdguardTeam/AdGuardFilters https://github.com/AdguardTeam/AdGuardFilters