{"id":10500,"date":"2026-09-03T10:30:00","date_gmt":"2026-09-03T08:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10500"},"modified":"2026-10-09T23:17:38","modified_gmt":"2026-10-09T21:17:38","slug":"privacy-sandbox-after-the-removals-which-technologies-chrome-keeps","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/privacy-sandbox-after-the-removals-which-technologies-chrome-keeps\/","title":{"rendered":"Privacy Sandbox After the Removals: Which Technologies Chrome Keeps and What That Means for Measurement"},"content":{"rendered":"

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.<\/p>\n\n

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.<\/p>\n\n

\n\"Two\n
Eight entries carry the same status, three carry a version number. The sort order is what each one asked the browser to accept.<\/figcaption>\n<\/figure>\n\n

What Is Left, and What Each Piece Does<\/h2>\n

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.<\/p>\n\n\n\n
Technology<\/th>Solves<\/th>Does not do<\/th>Default since<\/th><\/tr>\n<\/thead>\n
CHIPS<\/td>State for an embed that has to survive a page change<\/td>Recognition across embedding sites<\/td>Chrome 114<\/td><\/tr>\n
Storage Access API<\/td>Access to the unpartitioned cookie once permission is given<\/td>Access without a gesture and a decision<\/td>Chrome 119<\/td><\/tr>\n
FedCM<\/td>Federated sign-in without third-party cookies<\/td>Anything outside sign-in<\/td>Chrome 108<\/td><\/tr>\n<\/tbody>\n<\/table>\n\n

The Line Is Not First Party Against Third Party<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n\n

CHIPS Gives Each Embedding Site Its Own Cookie<\/h2>\n

The Partitioned<\/code> 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.<\/p>\n\n\n

Text<\/span>