# Privacy Sandbox APIs removed from Chrome: a version tell > Chrome is removing Topics and Protected Audience release by release, so whether runAdAuction exists tells a page which Chrome you really are. Source: https://mosaicbrowser.com/blog/privacy-sandbox-apis-removed ## Privacy Sandbox is retired, and its APIs are a version tell Chrome is removing Topics and Protected Audience release by release, so whether runAdAuction exists tells a page which Chrome you really are. ![An API Chrome removed is an API a page can miss, beside a screenshot: mosaic settings showing the installed Tesseract Chrome engine and its version](https://mosaicbrowser.com/covers/privacy-sandbox-apis-removed.webp) 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. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Machines that exist](https://mosaicbrowser.com/features/real-fingerprints) ## 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](https://mosaicbrowser.com/blog/enumeration-order-fingerprint)). ## 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](https://mosaicbrowser.com/blog/twenty-apis-chrome-lacks). 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](https://mosaicbrowser.com/blog/anti-detect-chromium-version-lag) 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](https://mosaicbrowser.com/blog/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. ## Questions ### Which Privacy Sandbox APIs is Google removing from Chrome? The advertising and measurement ones: Topics, Protected Audience, Attribution Reporting, Shared Storage, Private Aggregation and the APIs built on them. Google said it would keep a few pieces that were never about ads, such as CHIPS, FedCM and Private State Tokens. Chrome Platform Status lists the release each removal lands in. ### How can I tell if my browser still has Protected Audience or Topics? On an https page, open the console and run 'runAdAuction' in navigator and 'browsingTopics' in document. Both members need a secure context, so on about:blank they read false in every browser, which proves nothing. ### Why would a missing API reveal an anti-detect browser? Because the set of APIs a browser has is fixed by its build. A browser that claims one Chrome version and carries an API that version removed, or lacks one it still ships, is describing a different build from the one it names. ### Does Mosaic remove these APIs itself? No. Tesseract Chrome is built from stock Chromium source, so it gains and loses web APIs when Chromium does. What we control is which major it tracks and that it does not run the field-trial testing config, which once removed Protected Audience from our engine while Chrome still had it. ## Related [Twenty APIs Chrome doesn't have: Chromium's field trials](https://mosaicbrowser.com/blog/twenty-apis-chrome-lacks): Unbranded Chromium runs its field-trial testing config at every launch. Against Chrome 153 that was 20 API differences, and one switch moved them all. [How far behind Chrome stable is your anti-detect browser?](https://mosaicbrowser.com/blog/anti-detect-chromium-version-lag): Real Chrome updates itself, so an engine a few majors old claims a browser almost nobody runs. Our move from 153 to 154 took a 93-minute rebuild. [Sorting the property list hid the question](https://mosaicbrowser.com/blog/enumeration-order-fingerprint): Property enumeration order is a fingerprint that sorted diffs can't see. Compared unsorted, our engine differed from Chrome only in its 20 field-trial entries. [JA4 moves with the Chrome major, and that is not a tell](https://mosaicbrowser.com/blog/ja4-moves-with-the-chrome-major): Chrome 152 read t13d1517h2 and 153 read t13d1518h2: one TLS extension apart. Compare a JA4 only against a Chrome of the same major version. [Machines that exist: fingerprints drawn from real hardware](https://mosaicbrowser.com/features/real-fingerprints): Mosaic draws each profile's GPU, screen, CPU, memory and fonts from one real device, so the parts of a fingerprint agree with each other and with the host. [Why every Mac's Chrome says Mac OS X 10_15_7](https://mosaicbrowser.com/blog/mac-os-x-10-15-7): Chrome froze the macOS version in its User-Agent, so every Mac claims 10.15.7. The real one is in Sec-CH-UA-Platform-Version, a hint sites must ask for. [Why the User-Agent says Windows 10 on Windows 11](https://mosaicbrowser.com/blog/windows-11-user-agent-windows-10): Windows 11 and 10 both send Windows NT 10.0 in the User-Agent. Only the platformVersion client hint, 13 or higher, says Windows 11. [Why Chrome's User-Agent says 0.0.0](https://mosaicbrowser.com/blog/chrome-user-agent-0-0-0): Chrome zeroes everything after the major, so the User-Agent says 0.0.0 and the build moves to Sec-CH-UA-Full-Version-List. A real build in the UA is a tell. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.