Get Inspired
Docs
Blog
Articles
The Privacy Sandbox
What is the Privacy Sandbox? Proposal lifecycle in the Privacy Sandbox Timeline Glossary and key concepts Privacy Sandbox events Privacy Sandbox demos Blog Privacy Sandbox videos
Chrome-facilitated testing Relevance and measurement unified origin trial Enroll your site API status and feature releases
Privacy Sandbox testing FAQs Privacy-related compliance FAQs
Feedback
Prepare for phasing out third-party cookies Related Website Sets Related Website Sets: developer guide How Chrome evolved the First-Party Sets proposal Cookies Having Independent Partitioned State (CHIPS) Storage Partitioning Fenced frames
Federated Credential Management API Federated Credential Management API: developer guide Federated Credential Management API updates
Shared Storage Shared Storage API walkthrough
IP Protection Privacy Budget Bounce tracking mitigations
User-Agent reduction User-Agent reduction snippets
Topics API overview Topic classification Developer guide Integration guide Experiment and participate Topics API demos Test topic inference in a colab Topics API latest updates
Protected Audience API Experiment and participate
Protected Audience API: developer guide Seller guide: run ad auctions Buyer guide: join interest groups and generate bids Protected Audience API auction reporting Sequential auction setup with header bidding and multi-seller Protected Audience auction Improve Protected Audience API auction latency Opt-out of the Protected Audience API Report on Protected Audience API auction results Troubleshoot the Protected Audience API
Status of pending Protected Audience API capabilities Protected Audience API walkthrough
Content selection with Shared Storage Creative rotation Creative selection by frequency A/B Testing Known customers
Maximize ad relevance
Attribution Reporting overview Attribution Reporting end-to-end Experiment and participate Why Chrome plans to ship the Attribution Reporting API
Introduction to debug reports Set up debug reports Debugging cookbook
Attribution Reporting API developer guide Get started with Attribution Reporting Register attribution sources Register attribution triggers Prioritize specific clicks, views, or conversions Define custom rules using filters Prevent duplication in reports Custom report windows Register multiple reporters Report schedules Constraints on Aggregation Reporting data Web-to-app and app-to-web measurement Understanding aggregation keys Understanding noise in summary reports Working with noise Contribution budget for summary reports
API updates
Private Aggregation API Private Aggregation API fundamentals Experiment and participate Unique reach measurement User demographic reporting K+ frequency measurement
Aggregation Service Summary reports
Private State Tokens

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: 日本語

Kevin K. Lee
Kevin K. Lee

Developer Relations Engineer, Google Chrome

Twitter GitHub
Milica Mihajlija
Milica Mihajlija

Milica is a technical writer at Chrome.

Website Twitter GitHub

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

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.