Storage Partitioning

# Implementation status

• Storage Partitioning proposal is open for discussion.
• Chrome Platform Status
• Available for testing in Chrome Beta version 105.0.5195.17 and later.

The feature launch is planned for early 2023, depending on the stability and compatibility. Testing third-party storage partitioning now in an Origin Trial and filing bugs will help uncover any potential issues and resolve them before the General Availability 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 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

# After

# How to test storage partitioning

To try it out:

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

Participate in early testing and report bugs to help the Chrome team identify and fix any unexpected behavior before the stable launch. Blob URL and Clear-Site-Data header APIs are under active development and are not available for testing yet.

# 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 will 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 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 mitigation 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.

# 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.

• GitHub: Read the proposal, raise questions and participate in discussion.
• Developer support: Ask questions and join discussions on the Privacy Sandbox Developer Support repo.