Eight Removed, Three Left Standing
Contents
The Privacy Sandbox status page carries the same phrase eight times on 14 August 2026: intent to deprecate and remove. Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage, Fenced Frames, Related Website Sets, IP Protection. Three entries carry a different one – supported by default, with a Chrome version beside it.
Read as a casualty list that says little beyond the obvious. Read as a sorted list it says something worth carrying forward: the eight and the three differ in one respect, and it is not the one the name of the project suggests.
What Is Left, and What Each Piece Does
Three technologies came out of the project and stayed in the browser. None of them is new, none of them was controversial, and all three solve a problem that exists whether or not anyone sells advertising.
| Technology | Solves | Does not do | Default since |
|---|---|---|---|
| CHIPS | State for an embed that has to survive a page change | Recognition across embedding sites | Chrome 114 |
| Storage Access API | Access to the unpartitioned cookie once permission is given | Access without a gesture and a decision | Chrome 119 |
| FedCM | Federated sign-in without third-party cookies | Anything outside sign-in | Chrome 108 |
The Line Is Not First Party Against Third Party
The obvious reading is that the browser dropped whatever served advertising and kept whatever serves the site. Six of the eight fit that neatly. Topics profiled the interests, Protected Audience ran the auction, Fenced Frames rendered its result, Attribution Reporting counted the conversions, Private Aggregation returned the numbers, and Shared Storage held the state the others shared. IP Protection sits slightly apart, hiding an address rather than replacing a cookie, but it is still a defence against the same trade.
Related Website Sets does not fit at all. It was built for a single operator running several domains – a shop on one, a support desk on another, a login on a third – and it went out with the rest. The reason is its mechanism rather than its purpose: it granted cross-site access on the strength of a list the operator declared about itself. The browser was asked to take that declaration as sufficient.
That is where the line runs. Partitioning needs no trust at all, because nothing crosses. Asking needs none either, because the answer comes from the one being asked. A declared list needs a great deal of it, and the trust is extended by the browser on behalf of someone who is not in the room.
CHIPS Gives Each Embedding Site Its Own Cookie
The Partitioned attribute changes what the storage key contains. Without it, an embed sets one cookie and finds it again everywhere it appears – which is exactly the property that made third-party cookies useful and got them removed. With it, the key gains the top-level site, so the same embed on two different sites is holding two unrelated cookies.
Set-Cookie: __Host-widget=7f3a9c; Path=/; Secure; HttpOnly;
SameSite=None; Partitioned; Max-Age=2592000
without Partitioned key = (widget.example)
one cookie, the same on every embedding site
with Partitioned key = (widget.example, shop.example)
(widget.example, blog.example)
one cookie per embedding site, no bridgeFor a chat widget, a video player or a payment frame that only has to remember something for the duration of a visit, this costs nothing. For anything that was quietly using the same cookie to recognise a return across sites, it removes the capability outright, and no combination of attributes brings it back.
The Storage Access API Asks, and Its Shortcut Went With the List
Where an embed genuinely needs the unpartitioned cookie – a signed-in account inside a frame is the usual case – the Storage Access API is the route. The frame calls document.requestStorageAccess() after a user gesture, the browser decides, and the decision may involve a prompt. Access lasts for the current context and has to be requested again later.
There was a shortcut. document.requestStorageAccessFor() let the top-level page request access on behalf of an embed, which spared the user a prompt inside a frame they had not interacted with. It only ever made sense with a declared set of related domains behind it, and it was deprecated alongside Related Website Sets. Any integration built on it needs the frame to ask for itself again, gesture and all.
FedCM Removes the Redirect Chain, Not the Consent
Federated sign-in used to work by bouncing the browser through the identity provider and back, carrying state in redirects and third-party cookies. FedCM replaces the mechanics: the browser talks to the identity provider itself, renders the account chooser as browser interface rather than page content, and hands back a token.
What it does not replace is the decision. The chooser is still a prompt, the account is still selected deliberately, and a provider that is not already signed in produces nothing. It is a better-behaved version of a flow that already required consent, not a way around one.
What This Changes for a Measurement Setup
Anything designed around Topics, Protected Audience or Attribution Reporting no longer has a target. Such a plan is not late, it is void, and the sensible response is to stop maintaining the branch rather than to wait for a replacement announcement.
An embed that keeps state needs Partitioned, and needs to accept what that means: the identifier is now per embedding site. For a measurement embed this is not a defect to work around but the whole point of the attribute.
Recognition across domains is back where it stood before the project started. A first-party identifier per domain, joined on a server if there is a lawful basis for joining them, and left unjoined otherwise – which was the honest answer throughout and is now also the only one. What the browser still offers without charge is partitioning and a way to ask. Both are simple to build against, and neither is likely to be withdrawn in the next round, because they are what the last round left behind.
Related articles
