privacy-budget

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-...

ibly as part of large, heterogeneous groups. So, this is a glorified version of Do Not Track but with budgets and involves more telemetry to be shared with browser vendors and/or websites? How is this even in the conversation? How about browsers simply block attempts to fingerprint a user or allow extensions that do? Penalise websites known to fingerprint from search results? Display a big red banner before the user navigates to that website? Proxy such websites, if the user so agrees and send only content that's relevant (like some kind of an advanced read-mode)? -- > https://github.com/dvorak42/trust-token-api#motivation > Preventing fraud is a legitimate use case that the web should support, but it shouldn’t require an API as powerful as a stable, global, per-user identifier. In third party contexts, merely segmenting users into trusted and untrusted sets seems like a useful primitive that also preserves privacy. This kind of fraud protection is important both for CDNs, as well as for the ad industry which receives a large amount of invalid, fraudulent traffic. I like the concept of issuing tokens and then redeeming them later... but it seems like a lot of elaborate crypto to only really prevent ad-fraud (the advanced fingerprinting techniques they talk about elsewhere cannot prevent it?). It opens up another attack surface, whilst also not being truly anonymous to the first-party that issues the tokens. -- > https://github.com/csharrison/conversion-measurement-api > Since the ads industry today uses common identifiers across advertiser and publisher sites to track conversions, these common identifiers can be used to enable other forms of cross-site tracking. > This doesn’t have to be the case, though, especially in cases where identifiers like third party cookies are either unavailable or undesirable. A new API surface can be added to the web platform to satisfy this use-case without them, in a way that provides better privacy to users. This is all out battle against content-blockers. Block third-party cookies, and still you're in their cross-hairs... but wait... this is more privacy-friendly, so will you, the end-user, please suck it up. -- I hope Raymond Hill is reading and already thinking of ways to mitigate this. I see this as push by Chrome in response to the ecosystem Brave is building and the direction Apple is going, and simply taking control of the privacy conversation by doing what's best for them, all around, without holding back any punches. That's not to say, Apple isn't doing the exact same thing! BigTech can't be trusted with privacy, and this post kind of proves it? "It is difficult to get a man to understand something, when his salary depends on his not understanding it." Indeed.