How Chromium State Partitioning Stops Cross-Site Tracking

This article provides an overview of how State Partitioning in the Chromium web browser protects user privacy by preventing third-party trackers from correlating user activity across different websites. It explains the historical flaw of unpartitioned browser storage, the mechanics of double-keyed isolation, the specific browser APIs affected, and how partitioning neutralizes both direct and side-channel tracking methods.

The Flaw of Unpartitioned Browser State

Historically, web browsers stored data—such as local storage, caches, and databases—using a single key: the origin of the script requesting the storage. If a third-party tracker (tracker.com) was embedded as an iframe on both news-site.com and shopping-site.com, the browser granted tracker.com access to the exact same storage bucket on both websites.

This allowed the third party to drop a unique identifier into its storage while a user visited the news site, and then read that exact same identifier when the user visited the shopping site. Consequently, the tracker could easily correlate the user's browsing history across the web without their knowledge.

The Solution: Double-Keyed Storage

State Partitioning eliminates this vulnerability by changing how Chromium indexes stored data. Instead of keying storage solely by the third-party origin, Chromium implements "double-keying" (and in some cases, triple-keying).

With State Partitioning, the browser creates a unique storage key composed of two main elements:

  1. The Top-Level Site: The primary website the user is actively visiting (shown in the address bar).
  2. The Frame Origin: The third-party domain embedded within that top-level site.

Using the previous example, when tracker.com runs on news-site.com, its storage is locked to the key (news-site.com, tracker.com). When the user moves to shopping-site.com, the tracker is assigned a completely different key: (shopping-site.com, tracker.com).

Because the keys do not match, tracker.com is placed into separate, isolated sandboxes on each site. It cannot access the data it stored on the previous site, making cross-site user correlation via browser storage impossible.

What Chromium Partitions

Trackers do not rely solely on traditional cookies; they use various browser mechanisms to fingerprint and track users. To prevent workarounds, Chromium partitions multiple layers of browser state:

1. Storage APIs

All client-side storage mechanisms are partitioned. If a third-party script attempts to save a tracking ID using localStorage, sessionStorage, IndexedDB, or the File System API, that data is strictly confined to the top-level site where it was created.

2. Communication APIs

Browsers provide APIs that allow different tabs or iframes from the same origin to talk to each other in real time. Trackers previously abused this by opening communication channels between two different websites open in separate tabs to sync user IDs. Chromium partitions BroadcastChannel, SharedWorker, and ServiceWorker APIs, ensuring a third party on Site A cannot send messages to an instance of itself running on Site B.

3. Network State and HTTP Cache

Even without storage, trackers could deduce a user's history through "timing attacks" and cache probing. A tracker on Site B could request a specific image or script known to be used only on Site A. If the file loaded instantly from the browser's cache, the tracker knew the user had recently visited Site A.

Chromium prevents this by partitioning the HTTP cache, DNS cache, and network socket pools. If tracker.com caches a file on Site A, it must download it again from the network on Site B, blinding the tracker to the user's previous activity.

Summary of the Privacy Impact

By enforcing State Partitioning, Chromium fundamentally alters the architecture of the web from a model of shared third-party access to one of strict isolation. Third-party services can still function—such as saving user preferences for an embedded video player on a specific site—but their ability to aggregate data into a global profile of the user's browsing habits is completely severed.