[HN Gopher] The CNAME of the Game: Large-scale Analysis of DNS-b...
___________________________________________________________________
The CNAME of the Game: Large-scale Analysis of DNS-based Tracking
Evasion
Author : spenvo
Score : 53 points
Date : 2021-03-04 19:37 UTC (3 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| c7DJTLrn wrote:
| So tired of this arms race. The Web is an absolute joke.
| airstrike wrote:
| Bring back geocities!
|
| No, really
| zaik wrote:
| So... Gemini?
| jedisct1 wrote:
| `dnscrypt-proxy` blocks these, as well as the SVCB and HTTPS
| variants.
| WarOnPrivacy wrote:
| 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.
| tyingq wrote:
| _" 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 wrote:
| 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?).
| dang wrote:
| The submitted title ("CNAME tracking's a disaster. uBlock Origin
| blocks it in FF. Chrome users are SOL") broke the site guidelines
| badly. Accounts that do that eventually lose submission
| privileges, so please don't do that.
|
| " _Please use the original title, unless it is misleading or
| linkbait; don 't editorialize._"
|
| https://news.ycombinator.com/newsguidelines.html
| blitz_skull wrote:
| Aaaaaaaand, I'm now reading this from FF. Google needs to get its
| shit together.
| spenvo wrote:
| 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
|
| 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.
| jaytaylor wrote:
| 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 wrote:
| 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 wrote:
| Anecdotally, I switched to FF after the manifest v3 changes
| were announced.
| croes wrote:
| Chrome is the new IE. Everybody knows it's bad, but it's
| standard.
| minikites wrote:
| Except web developers love Chrome, which is why Google
| might actually win control of the web.
| jimbob45 wrote:
| Amen. FF's dev tools are like Windows 95 to Chrome's
| Windows 7.
| Daho0n wrote:
| I very much doubt that. Not only do more and more people use
| Chrome but even on HN you see lots of people using and
| recommending both Chrome but also derivatives like Brave.
| When Firefox is dead Google will IMO kill off what little API
| access is left to block tracking and ads effectively.
| thrwwy0304 wrote:
| 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 wrote:
| 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 wrote:
| The third of those. This isn't a technical problem, it's a
| "greedy maw of the surveillance economy" problem.
| donmcronald wrote:
| 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 wrote:
| 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 wrote:
| 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.
| thrwwy0304 wrote:
| Your example is reliant on UserA visiting example.com
| having the same "auth token" as UserA visiting other.net.
|
| That's not the case. Both example.com and other.net are
| likely to be generating completely unique auth tokens.
|
| example.org and other.net can certainly both coordinate
| with evil.com to manually share more detail (e.g. the
| current user is UserA@gmail.com), but if that's the
| threat then browsers have no chance at offering
| protection.
| ballenf wrote:
| 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.
| baal80spam wrote:
| Strange, I don't see this option in my uBlock for FF.
| tyingq wrote:
| 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
| mixedCase wrote:
| 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 wrote:
| It's already included in the native adblocker in Brave (oct
| 2020)
|
| https://brave.com/privacy-updates-6/
| roylez wrote:
| 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?
| Spivak wrote:
| 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.
| anfilt wrote:
| 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 wrote:
| It's not any worse than third party scripts, which give you
| full access to the DOM.
| colinclerk wrote:
| 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.
___________________________________________________________________
(page generated 2021-03-04 23:00 UTC)