Participate in the origin trial for non-cookie storage access through the Storage Access API

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

Chrome 115 introduced changes to storage, service workers, and communication APIs by partitioning in third-party contexts. In addition to being isolated by the same-origin policy, the affected APIs used in third-party contexts are also isolated by the site of the top-level context.

Sites that haven't had time to implement support for third-party storage partitioning are able to take part in a deprecation trial to temporarily unpartition (continue isolation by same-origin policy but remove isolation by top-level site) and restore prior behavior of storage, service workers, and communication APIs, in content embedded on their site. This deprecation trial is set to expire with the release of Chrome 127 on September 3, 2024. Note that this is separate from the deprecation trial for access to third-party cookies: this is just for access to storage.

As a long-term solution to address certain use cases disrupted by third-party non-cookie storage partitioning, Chrome is proposing the ability for third parties to request storage/communication access (both cookie and non-cookie) through the Storage Access API (shipping as of Chrome 117), which already allows third parties to request cookie access.

As of Chrome 120, this proposal will be available for experimentation through an origin trial. Developers should participate in this origin trial to evaluate how the proposed solution addresses their use cases to ensure they are prepared before the deprecation trial ends.

Origin trial details

Beginning in Chrome 120, Chrome will support an origin trial, StorageAccessAPIBeyondCookies, to enable the proposed extension of the Storage Access API (backwards compatible) to allow access to unpartitioned storage (cookie and non-cookie) in a third-party context.

Mechanics

The API can be used as follows (JavaScript running in an embedded iframe):

// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);

If you want just specific API access rather than access to all you can pass the names of just the API handles you need. For example, you could pass {sessionStorage: true} to just get access to Session Storage, or {indexedDB: true, locks:true} to get access to IndexedDB and Web Locks.

Beyond calling this additional extension, access to non-cookie storage would match the current requirements for cookie access through the Storage Access API. For example, in Chrome, no prompt is shown when the origins are in the same Related Website Set (RWS, the new name for First Party Sets). Origins that are not part of the same RWS would be subject to the prompting requirements of the Storage Access API in Chrome.

Duration

The origin trial will be available from Chrome 120 until Chrome 125 (or after August 6, 2024 in any milestone).

Scope

Only DOM Storage (session and local storage), Indexed DB, and Web Locks are available in Chrome 120.

Cache Storage, Origin Private File System, Quota, Blob Storage, and Broadcast Channel were added in Chrome 121.

Shared Workers and control over the inclusion of cookies were added in Chrome 123.

Dedicated Workers inherit access to unpartitioned cookies if requestStorageAccess was called before the worker was created as of Chrome 120 (this does not require using the Storage Access API handle).

Participate

  1. Assess how you use cookie and non-cookie storage in a third-party context. The example use cases may help in understanding whether this proposal may fit your needs.
  2. Launch Chrome version 120 (or later) and ensure the test-third-party-cookie-phaseout flag is enabled.
  3. If you want to test the feature locally without first setting up an origin trial token, you can enable #enable-experimental-web-platform-features in your browser.
    1. Once you are done testing locally you can register for the StorageAccessAPIBeyondCookies origin trial and get a token for your domains. For more detailed instructions, visit Get started with origin trials. The guide to troubleshooting Chrome origin trials provides a full checklist for ensuring your token is correctly configured.
    2. Embed that origin trial token in the iframe you need to use the Storage Access API handle within, using an HTTP header, HTML meta tag, or programmatically. Note that the token must be embedded by any frame that wishes to use this API, embedding it in the parent frame won't enable the API in child frames.
  4. Call document.requestStorageAccess(...) to get the Storage Access API handle in the cross-site iframe. See Storage Access API documentation for the requirements to have this call succeed.
  5. Migrate the storage related in your iframe to use the Storage Access API handle if it's available. For example, calls to window.sessionStorage.setItem(...) become handle.sessionStorage.setItem(...).
  6. Open your website and verify that the storage access handle is working as intended.
  7. To stop participating in the origin trial, remove the token you added in step 3.
  8. Submit feedback or raise any issues you encounter to the Storage Access API Non-Cookie Storage GitHub repository.

Demo: using the Storage Access API to access unpartitioned Local Storage

The following demo shows how to access unpartitioned Broadcast Channels from a third-party iframe using the Storage Access API:

https://saa-beyond-cookies.glitch.me/

The demo requires Chrome 121 or higher with the test-third-party-cookie-phaseout flag enabled.

Additional resources