Shared Storage and Select URL updates: cross-origin worklets, and saved queries

Tara Agyemang
Tara Agyemang
GitHub LinkedIn

Chrome 130 introduces changes to the Shared Storage API to enable the use of cross-origin worklet scripts with createWorklet() and addModule(). We're also introducing updates to the Select URL API with Shared Storage in Chrome 132 with the support of saved queries.

Diagram showing enrolled sites can write any type of key/value data into Shared Storage, but reading the data out is restricted to specific output APIs.
The Shared Storage API allows enrolled sites to write any type of key/value data into Shared Storage, but reading the data out is restricted to specific output APIs.

Cross-origin worklets with the Shared Storage API in Chrome 130

We've introduced changes to the Shared Storage API in Chrome 130 to give you more flexibility when working with cross-origin worklet scripts.

What's changed

We've removed the same-origin restriction for addModule() so you can now load worklet scripts from any origin. Cross-origin worklet scripts enable key use cases such as hosting worklet scripts on CDNs. When the worklet script is cross-origin to the invoking browsing context, the invoking context's origin is used as the data partition origin for accessing shared storage.

To match the new addModule() behaviour, and reduce potential confusion, the dataOrigin property has been added to the createWorklet() call to allow reading and writing to a shared storage data partition that is different from the invoking browsing context. This gives you more granular control over which origin's shared storage is accessed by each worklet, even when using cross-origin worklet scripts.

How has it changed

As of Chrome 125, a third-party cross-origin script on a page is able to create cross-origin worklets without the need for cross-origin iframes by invoking createWorklet(url). Previously, createWorklet(url) used the script URL (url) origin as the data partition origin, regardless of the invoking context.

In Chrome 130, to align with the new addModule() behaviour, createWorklet() also uses the invoking context as the default data partition origin. To continue using the script URL origin as the data partition origin, a new property dataOrigin is being introduced to allow you to explicitly set the data partition origin.

The new dataOrigin property accepts "script-origin", which sets the data partition origin as the script's origin, and "context-origin" which sets the data partition origin as the invoking browsing context's origin. In a future release we also plan to support custom data partition origins, where a worklet script can access shared storage data from an arbitrary origin on an opt-in basis.

When loading a cross-origin script with data origin set to "script-origin", the request for the script sent from the browser will include a "Sec-Shared-Storage-Data-Origin: <origin>" header. To enable this, the script must also include the "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" opt-in response header.

How to use

If you're already using createWorklet() with the script origin as the worklet's data partition origin, you can set the dataOrigin as follows:

sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});

Since createWorklet() allows the creation of a cross-origin data partition and the creation of multiple worklets, we encourage you to transition to createWorklet() over uses of addModule().

We've updated the developer documentation to reflect these changes and provide further guidance.

Saved queries with the Select URL API in Chrome 132

We're introducing updates to the Select URL API with Shared Storage in Chrome 132 with the support of saved queries.

What's changing

The Select URL API currently has two per-page-load budgets that restrict the number of calls made to the API on each page-load. We're introducing the ability to save and reuse queries on a per-page basis. When you use a saved query, the per-page-load budgets are charged the first time a saved query is run, but not for subsequent runs of the saved query during the same page-load.

How to implement saved queries

Starting with the Chrome 132 release, you can use the savedQuery parameter in the options for selectURL() with the name of the query:

await sharedStorage.selectURL('experiment', urls, {
  savedQuery: 'control_or_experiment',
  keepAlive: true
});

Use the same savedQuery name for every call to selectURL() to ensure follow-up queries are charged to the same budget.

We've updated the documentation to reflect these changes and provide additional details on budgeting for selectURL().

Engage and share feedback

Note that the Shared Storage API proposal is under active discussion and development and therefore subject to change.

We're eager to hear your thoughts on the Shared Storage API.

Stay Informed

  • Mailing List: Subscribe to our mailing list for the latest updates and announcements related to the Shared Storage API.

Need Help?