What Storage Partitioning Changed About Tracking

Storage partitioning is one of the larger changes browsers have made to how embedded code behaves. It did not remove any API, but it changed what those APIs return depending on where the code is running.

Shared storage was the old assumption

For most of the web's history, storage belonged to the origin that wrote it. A script loaded on many different sites read and wrote the same cookie jar everywhere.

That single shared bucket was what made cross-site continuity work. An identifier written while a user was on one publisher was readable when the same script loaded on another.

Nothing about this was hidden or exploitative in a technical sense. It was the straightforward consequence of keying storage on the origin of the script's own host.

Partitioning keys storage to the top-level site

Under partitioning, the storage key becomes a pair: the embedded origin plus the site the user actually visited. The same script on two publishers now sees two separate buckets.

This applies broadly across storage surfaces, covering cookies, local storage, caches and several network-level state mechanisms. The intent is that no state crosses a top-level site boundary.

From the script's perspective nothing errors. It writes a value, reads it back successfully, and simply never sees the value it wrote elsewhere.

Third-party scripts lost their continuity

The practical effect is that cross-site identity built on stored state stopped working. Systems that had assumed a stable identifier across publishers found themselves seeing a new visitor each time.

Measurement suffered first, because attribution depends on recognising the same person across a boundary. Frequency capping and cross-site personalisation degraded in the same way.

Some of this was absorbed by moving identity to the first party, where the publisher holds the state and shares only what it chooses. That shifts responsibility rather than removing it.

Fingerprinting became relatively more attractive

Because fingerprints are recomputed rather than stored, partitioning does not touch them. A technique that depends on observation is unaffected by rules about state.

This is the predictable second-order effect, and browser engineers describe it openly. Constraining one mechanism increases the pressure on the mechanisms that remain.

The response has been to reduce what browsers passively reveal, which is slower and more disruptive work. Removing an information source breaks legitimate uses alongside unwanted ones.

What partitioning does not touch

Server-side linkage is untouched. If two sites share data through a back-end integration, the browser's storage rules are not part of that path.

Logged-in identity is also unaffected, because the user supplies the link deliberately. Partitioning constrains silent cross-site state, not identity a person chose to assert.