Privacy Sandbox is retired, and its APIs are a version tell

Google has retired the Privacy Sandbox advertising APIs, Topics, Protected Audience, Attribution Reporting, Shared Storage, Private Aggregation and the rest, and Chrome is taking them out in stages, one release at a time. For anyone who reads browser fingerprints that turns a set of ad APIs into a version marker: whether navigator.runAdAuction or document.browsingTopics exists is one line of JavaScript, and the right answer depends on exactly which Chrome you claim to be.

Which Privacy Sandbox APIs are being removed from Chrome

The retired set is the one built to replace third-party cookies for advertising: Topics (document.browsingTopics()), Protected Audience (navigator.joinAdInterestGroup(), navigator.runAdAuction() and their relatives), Attribution Reporting, Shared Storage and Private Aggregation, plus pieces that only existed to serve them. Google said a few parts of the old programme stay, because they are about identity and cookies rather than ads: CHIPS, FedCM and Private State Tokens among them.

The removal is not one event. Each API goes through Chromium's usual path, deprecation and then removal, and each lands in its own release. Chrome Platform Status has an entry per feature with the milestone; that page is the place to check a specific version, and we do not reproduce the table here because it is the kind of fact that is out of date by the next release.

How it works: Machines that exist

Why an API's presence is a fingerprint

A page does not need to call Protected Audience to learn something from it. It only needs to ask whether it is there:

'runAdAuction' in navigator          // Protected Audience
'joinAdInterestGroup' in navigator
'browsingTopics' in document         // Topics
'sharedStorage' in window            // Shared Storage

Each answer is fixed by the build. A real Chrome of one major either has the member or does not, on every machine that runs it, so a fingerprinting script can turn four booleans into a check of the version the User-Agent claims. That check costs nothing and cannot be fooled by editing the User-Agent string, because the string and the API set come from different places.

Two cautions if you run it yourself. These members are marked [SecureContext], so read them on an https page: on about:blank the origin is opaque and every browser says false, which we once reported as a finding before we noticed. And the order properties are listed in is readable too, so an API that is present in the wrong place is as visible as one that is missing (sorting the property list hid that question).

The time Chrome had them and our engine did not

We met this surface from the other direction, while the Chrome we compare against still had every one of these APIs. Measured against the Google Chrome 153 on our build Mac, our engine was missing navigator.runAdAuction, joinAdInterestGroup, protectedAudience, adAuctionComponents and nine more Protected Audience members, plus Document.browsingTopics. It also had window.ModelContext and window.WebMCPEvent, which that Chrome did not.

None of it was our patches. An unbranded Chromium build compiles fieldtrial_testing_config.json in and applies it at every launch, and that config switched the ad APIs off and two experimental ones on. Google Chrome does not run that file. --disable-field-trial-config moved all twenty differences in one step, and Tesseract Chrome has been launched with it ever since. The full hunt, including the two theories that were wrong first, is in twenty APIs Chrome doesn't have.

The lesson carries straight over to the retirement. Then, a missing runAdAuction marked us as not-Chrome. As Chrome removes it, a present runAdAuction will mark any browser claiming a newer Chrome as an older build. The API did not change; what it says about you depends on the version beside it.

Every engine has to follow Chrome on the same major

That is why the API surface and the claimed version have to move together. An anti-detect browser built on an older Chromium but claiming a current Chrome keeps every API the current one has dropped, and a page asking four questions finds the gap. One that claims its true, older version is consistent but increasingly rare, because real Chrome updates itself (how far behind stable an engine can sit has what our own move from 153 to 154 took). Spoofing the APIs away in page script is the third option, and the worst: a deleted member leaves traces in property order and in the realms the script did not reach.

What Mosaic does is plainer. Tesseract Chrome is built from stock Chromium source, so when a removal of Topics or Protected Audience lands in Chromium's source, our engine loses the API in the same release, with no patch of ours involved. We track a current stable Chrome major and compare the engine against the machine's own Google Chrome of that same major, not against a build nobody browses with, because a comparison across majors would report every scheduled removal as a fault. TLS shows the same effect: JA4 moves with the Chrome major, so a hash is only comparable within one.

To check a browser of your own, run the four lines above on an https page in it and in Google Chrome of the major it claims, on the same machine. Any line that differs is a difference a page can read.