Storage Partitioning

To prevent certain types of side-channel cross-site tracking, Chrome is partitioning storage and communications APIs in third-party contexts.

Implementation status

The feature has been enabled for all users on Chrome 115 and later.

What is storage partitioning?

To prevent certain types of side-channel cross-site tracking, Chrome is partitioning storage and communications APIs in third-party contexts.

Without storage partitioning, a site can join data across different sites to track the user across the web. Also, it allows the embedded site to infer specific states about the user in the top-level site using side-channel techniques such as Timing Attacks, XS-Leaks, and COSI.

Historically, storage has been keyed only by origin. This means that if an iframe from example.com is embedded on a.com and b.com, it could learn about your browsing habits for those two sites by storing and successfully retrieving an ID from storage. With third-party storage partitioning enabled, storage for example.com exists in two different partitions, one for a.com and the other for b.com.

Partitioning generally means that data stored by storage APIs like local storage and IndexedDB by an iframe will no longer be accessible to all contexts in the same origin. Instead, the data will only be available to contexts with the same origin and same top-level site.

Before

Diagram of storage APIs without partitioning.
Before storage partitioning, a.com and b.com can share data.
View full size diagram.

After

Diagram of storage APIs with partitioning.
After storage partitioning, b.com cannot access a.com's storage.
View full size diagram.

How to test storage partitioning

To try it out:

  1. Use Chrome Canary version 113 or higher.
  2. Visit chrome://flags/#third-party-storage-partitioning.
  3. Enable the "Third-party Storage Partitioning" flag.

Participate in testing and report bugs to help the Chrome team identify and fix any unexpected behavior before the stable launch.

Updated APIs

Storage APIs

Quota system
The quota system is used to determine how much disk space is allocated for storage. The quota system will manage each partition as a separate bucket to determine how much space is permitted, and when it is cleared.
The navigator.storage.estimate()will return the information of the partition. Chrome-only APIs such as window.webkitStorageInfo and navigator.webkitTemporaryStorage will be deprecated.

IndexedDB and Cache storage will use the new partitioned quota system.

Web Storage API

The Web Storage API provides mechanisms by which browsers can store key/value pairs. There are two mechanisms: Local Storage and Session Storage. They are not currently quota-managed, but will still be partitioned.

Origin Private File System

The File System Access API allows a site to read or save changes directly to files and folders on the device after the user grants access. Origin Private File System allows an origin to store private content to disk that can be easily accessed by the user, and will be partitioned.

Storage Bucket API

The Storage Bucket API is being developed for Storage Standard which consolidates various storage APIs such as IndexedDB and localStorage by using a new concept called buckets. The data stored in the buckets and the metadata associated with the buckets will be partitioned.

Clear-Site-Data header

Including the Clear-Site-Data header in the response allows a server to request to clear the data stored in the user's browser. Cache, cookies, and DOM storage can be cleared. Using the header will only clear the storage within one partition.

Blob URL store

A blob is an object that contains raw data to be processed, and a blob URL can be generated to access the resource. To support a use case for navigating in a top-level context to any blob URL (discussion), the blob URL store might be partitioned by the agent cluster instead of the top-level site. This feature will not be available for testing yet, and the partitioning mechanism may change in the future.

Communication APIs

Along with storage APIs, communication APIs that allow one context to communicate across origin boundaries are also partitioned. The changes mainly affect APIs that allow the discovery of other contexts via broadcasting or same-origin rendezvous.

For the following communication APIs, third party iframe will no longer be able to communicate with its same-origin context:

Broadcast Channel
Broadcast Channel API allows communication between browsing contexts (windows, tabs, or iframes) and workers of the same origin.

Cross-site iframe postMessage() where the relationship between contexts is clearly defined is not proposed to be changed.

SharedWorker

SharedWorker API provides a worker that can be accessed across browsing contexts of the same origin.

Web Locks

The Web Locks API allows code running in one tab or worker of the same origin to acquire a lock for a shared resource while some work is performed.

Service Worker API

The Service Worker API provides the interface for conducting tasks in the background. Sites create persistent registrations that create new worker context to respond to events, and that worker can communicate with any same-origin context. Also, the Service Worker API can change the timing of navigation requests leading to the potential for cross-site information leaks such as history sniffing.

Therefore, Service Workers registered from a third-party context will be partitioned.

Extension APIs

Extensions are programs that allow users to customize their browsing experience.

Extension pages (pages with a chrome-extension:// scheme) can be embedded on sites across the web, and in these cases, they will continue to have access to their top-level partition. These pages can also embed other sites, in which case those sites will have access to their top-level partition as long as the extension has host permissions for that site.

In addition, extensions can use the chrome.cookies API to interact with the cookies for a given site. This currently operates on cookies from all partitions in a way which can be surprising.

For more information, see the extension docs.

Engage and share feedback