How Chromium Implements CHIPS for Third-Party Services

This article provides a technical overview of how the Chromium web browser implements Cookies Having Independent Partitioned State (CHIPS). It explains how Chromium modifies its cookie storage architecture using double-keying, enforces security protocols through the Partitioned attribute, manages memory quotas, and isolates third-party state to prevent cross-site tracking while maintaining support for embedded web services.

The Shift to Double-Keyed Storage

Historically, Chromium stored cookies in a single global database keyed only by the domain that created the cookie. This allowed an embedded third-party service to read the same cookie across multiple unrelated websites, enabling cross-site tracking.

To implement CHIPS, Chromium alters its internal SQLite cookie database to use a "double-keyed" storage mechanism. When a third-party service sets a partitioned cookie, Chromium keys that cookie using two distinct pieces of information:

The Partition Key: The effective top-level domain plus one label (eTLD+1) of the website the user is currently visiting in the main browser tab.
The Host Key: The domain of the embedded third-party service setting the cookie.

If service.com is embedded on both site-a.com and site-b.com, Chromium creates two completely isolated cookie jars: one keyed to (site-a.com, service.com) and another keyed to (site-b.com, service.com). The embedded service can maintain state (such as a user's session in a customer support chat widget) on site-a.com, but it cannot access that state when the user visits site-b.com.

Network Stack Architecture and `CookiePartitionKey`

Within Chromium's C++ codebase, this isolation is managed by the network service using the CookiePartitionKey class.

When a user navigates to a webpage, the browser process establishes the top-level site's origin. As the rendering engine parses the page and encounters third-party subresources or iframes, Chromium attaches the CookiePartitionKey to the IsolationInfo object associated with those network requests.

When a network request is made to an embedded third-party server, Chromium's CookieMonster (the component responsible for managing the browser's cookie store) checks the request's CookiePartitionKey. It then queries the database exclusively for cookies that match both the third-party domain and that specific partition key, appending only those matched cookies to the HTTP Cookie header.

Enforcing the `Partitioned` Attribute

Chromium does not partition all third-party cookies automatically. Instead, it requires developers to explicitly opt into the behavior by including the Partitioned attribute in the HTTP Set-Cookie response header.

When Chromium's network stack parses a Set-Cookie header containing the Partitioned attribute, it runs strict validation checks before committing the cookie to storage. Chromium rejects the partitioned cookie unless it meets the following criteria:

Secure Context: The cookie must include the Secure attribute and be set over HTTPS.
Cross-Site Compatibility: The cookie must include SameSite=None to allow it to be sent in third-party contexts.

If these requirements are met, Chromium serializes the current CookiePartitionKey and writes the cookie to the isolated partition in the database. If the Partitioned attribute is omitted, Chromium treats the cookie as an unpartitioned third-party cookie, which is subject to standard third-party cookie blocking rules.

Resource Management and Quota Limits

Because partitioning multiplies the number of cookies stored on a user's device, Chromium implements strict quota limits per partition to prevent disk exhaustion and memory abuse.

Chromium enforces a limit of 180 cookies per domain, per top-level partition. Additionally, it imposes a 10 kilobyte total size limit for all cookies set by a specific third-party domain within a single partition. If an embedded service exceeds these limits on a given website, Chromium automatically evicts the oldest cookies within that specific partition without affecting the cookies stored by that same third party on other top-level websites.

Handling Ancestor Chains

To prevent security bypasses, Chromium also evaluates the entire frame ancestor chain when dealing with nested iframes. If a top-level site (site-a.com) embeds a third-party iframe (site-b.com), which in turn embeds a frame from the original site (site-a.com), Chromium recognizes the cross-site ancestor in the chain. In these scenarios, Chromium enforces partitioning rules based on the top-level document and marks the partition key with a specific cross-site ancestor bit, ensuring that nested contexts cannot be exploited to leak unpartitioned state.