DOdomenicd·Nov 23, 2025
As someone who used to work on Chrome, I can confirm that browser fingerprinting is indeed a nightmare.
Back in the early days of Privacy Sandbox, before that crashed and burned against the UK CMA not even letting Google remove third-party cookie support [0], there was a lot of optimism about how we were going to completely solve cross-site tracking, even in the face of determined adversaries. This had several ingredients; the biggest ones I can remember are:
1. Remove third-party cookie support
2. Remove unpartitioned storage support
3. IP protection at scale
4. Solving fingerprinting
In the end, well... at least we got 2, which has some security benefits, even if Chrome gave up on 1, 3, and 4, and thus on privacy. Anyway, everyone could tell that 4 was going to be the hardest.
The closest I saw to an overarching plan was the "privacy bu
Read the rest
dget" proposal [1], which would catalogue all the APIs that could be used for fingerprinting, and start breaking them (or hiding them behind a permission prompt, maybe?) if a site used too many of them in a row. I think most people were pretty skeptical of this, and the main person driving it moved off of Chrome in 2022. Mozilla has an analysis suggesting it's impractical at [2]. Some code seems to still exist! [3]
A key prerequisite of the privacy budget proposal was trying to remove passive fingerprinting surfaces in favor of active ones. That involved removing data that is sent to the server automatically, or freezing APIs like `navigator.userAgent` which are assumed infallible, and then trying to replace them with flows like client hints where the server needed to request data, or promise-based APIs which could more clearly fail or even generate a permissions prompt. This was quite an uphill battle, as web developers (both in ad tech and outside) would fight us every step of the way, because it made various APIs less convenient. Elsewhere people have cited one example, of reducing Accept-Language [4]. The other big one was the user agent client hints headers/API [5], which generated whole new genres of trolls on the W3C forums.
As Privacy Sandbox slumped more and more towards its current defeated state, people backed off from the original vision of a brilliant technical solution that worked even in the face of determined adversaries. Instead they retreated to stances like "if we just make it hard enough to fingerprint, it'll be obvious that fingerprinting scripts are doing something wrong, and we can block those scripts"; see e.g. [6]. Maybe that would have worked, I don't know, but it becomes much more of a cat-and-mouse game, e.g. needing to detect bundled or obfuscated scripts.
And now of course it's all over; the ad tech industry, backed by the UK CMA, has won and forced Google to keep third-party cookies forever, and with those in place, there's not really any point in funding the anti-fingerprinting work, so it's getting wound down [7]. The individual engineers and teams are probably still passionate about launching opt-in or Incognito-only privacy protections, but I doubt that align with product plans. I'm sure Google doesn't mind the end result all that much either, as having to migrate the world to privacy-preserving ad tech was going to be a big lift. Now all that eng power can instead focus on AI instead of privacy.
[0]: https://privacysandbox.com/news/privacy-sandbox-next-steps/
[1]: https://github.com/mikewest/privacy-budget
[2]: https://mozilla.github.io/ppa-docs/privacy-budget.pdf
[3]: https://chromium.googlesource.com/chromium/src/+/36dc3642bee...
[4]: https://github.com/explainers-by-googlers/reduce-accept-lang...
[5]: https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_...
[6]: https://privacysandbox.google.com/protections/script-blockin...
[7]: https://privacysandbox.com/news/update-on-plans-for-privacy-...