English
Deutsch
PolskiPrivacy Sandbox After the Removals: Which Technologies Chrome Keeps and What That Means for Measurement
Contents
- What Is Left, and What Each Piece Does
- The Line Is Not First Party Against Third Party
- CHIPS Gives Each Embedding Site Its Own Cookie
- The Storage Access API Asks, and Its Shortcut Went With the List
- FedCM Removes the Redirect Chain, Not the Consent
- What This Changes for a Measurement Setup
- Questions and answers
- Sources
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.
The list shows which technologies are marked for removal, but that alone does not explain the distinction. Comparing the eight entries marked for removal with the three retained ones reveals one difference worth examining, and it is not the one the project name 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.
Questions and answers
Does a cookie with the Partitioned attribute no longer need consent?
The obligation stays wherever it existed before. The consent rule in the ePrivacy Directive is tied to storing and reading information on the device, not to whether a cookie can be read across sites; CHIPS limits what the cookie can be used for, but it is still stored. Whether the exemption for strictly necessary storage applies depends on the purpose: a chat widget that does not work without the cookie has a better case than a measurement embed.
What shows whether a site still depends on one of the removed technologies?
The calls in its own code and in the tags it loads. Four places cover most cases:
- Scripts: calls to
document.browsingTopics(),navigator.joinAdInterestGroup(),navigator.runAdAuction(),window.sharedStorageanddocument.requestStorageAccessFor(), plus thefencedframeelement. - Markup and server responses: the
attributionsrcattribute on links, images and scripts, and theAttribution-Reporting-Register-SourceandAttribution-Reporting-Register-Triggerheaders. - The
Permissions-Policyheader with directives such asbrowsing-topics,join-ad-interest-group,run-ad-auctionorattribution-reporting. Directives the browser no longer knows are ignored; they do no harm, but they show what was once planned. - The file
/.well-known/related-website-set.jsonon every domain that was once submitted as part of a Related Website Set.
A match does not yet mean that something will break. Code that checks whether an interface exists before using it simply skips it; an unconditional call throws an error as soon as the function is gone and can abort the rest of the script. If the calls come from third-party tags, the change is the vendor’s to make; for the site’s own code, what the article says about the measurement setup applies: the sensible step is to stop maintaining the branch rather than to wait for a replacement.
Related articles
