Storage Partitioning

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

Published on Updated on

Translated to: 日本語

Implementation status

The feature is rolling out to a small percentage of users starting in Chrome 113. Depending on the stability and compatibility, it will be made fully available in Chrome Stable mid-year 2023. Testing third-party storage partitioning now and filing bugs will help uncover any potential issues and resolve them before the full rollout.

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 is embedded on and, 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 exists in two different partitions, one for and the other for

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.


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


Diagram of storage APIs with partitioning.
After storage partitioning, cannot access'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 "Experimental 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 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 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 customize the browsing experience for the user. With Manifest V2, extensions can create background pages that have the extension's origin, but can embed iframes with web content's origins.

Because partitioning the storage will break some use cases, a couple of mitigations will be provided. If the extension has host_permissions for the iframe origin, then the iframe will be treated as the top-level frame and not the extension page. If an extension embeds an iframe with an extension URL into a top-level site with host permissions, the iframe will be treated as first-party with the extension rather than partitioned by the top-level site.

Manifest V2 has been deprecated and will be removed. It is recommended to migrate to Manifest V3.

Engage and share feedback

The shared storage proposal is under active discussion and subject to change in the future. If you try these APIs and have feedback, we'd love to hear it.

Updated on Improve article

This site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies.