Intent to Ship: Support Cross-Origin Shared Storage Worklets

933 views
Skip to first unread message

Yao Xiao

unread,
Apr 19, 2024, 12:52:28 PMApr 19
to blink-dev
Contact emails
Specification
https://wicg.github.io/shared-storage/

Additional anticipated specification changes
https://github.com/WICG/shared-storage/pull/152

Blink component
Blink>Storage>SharedStorage

Summary:
We plan to ship the following changes to the Shared Storage API:
  • selectURL() and run() will be exposed on the SharedStorageWorklet interface. When calling on the default scoped worklet (i.e. sharedStorage.worklet.selectURL()/run()), the behavior is equivalent to calling sharedStorage.selectURL()/run().
  • Users can create new worklets via const worklet = await sharedStorage.createWorklet(url, options). This API can be used to start multiple and potentially cross-origin worklets from a single document.

Risks

Interoperability and Compatibility
The changes are fully backward compatible.

Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None

Security
Because the worklet's context origin will be that of the origin of the script URL, both "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" and CORS are required when fetching a x-origin worklet script. Even so, it is important that worklet script creators understand the implications of this. Their worklet, which accesses their origin's Shared Storage data, can be loaded and executed by a different party.

Privacy
In the case of creating or using a cross-origin worklet, if the worklet cannot be created because the user has denied storage for that site, then the promise will resolve (rather than reject) to prevent leaking cross-site data. A caller may still use timing attacks to know this information, but this is a minor privacy issue, as in reality very few users would set such preferences, and doing a wide search would incur a significant performance cost spinning up the worklets.

Debuggability
  • Shared Storage database contents for an origin can be viewed and modified within DevTools.
  • Shared Storage worklet can be inspected within DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All but WebView

Is this feature fully tested by web-platform-tests?
Yes

Finch feature name
SharedStorageAPIM125

Requires code in //chrome?
No

Estimated milestones
We intend to ship in M125.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5145686840705024

Vladimir Levin

unread,
Apr 19, 2024, 1:59:39 PMApr 19
to Yao Xiao, blink-dev
Is it possible to file position requests? (https://bit.ly/blink-signals)

Was there a TAG review filed for this as well?
 

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None

Security
Because the worklet's context origin will be that of the origin of the script URL, both "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" and CORS are required when fetching a x-origin worklet script. Even so, it is important that worklet script creators understand the implications of this. Their worklet, which accesses their origin's Shared Storage data, can be loaded and executed by a different party.

Privacy
In the case of creating or using a cross-origin worklet, if the worklet cannot be created because the user has denied storage for that site, then the promise will resolve (rather than reject) to prevent leaking cross-site data. A caller may still use timing attacks to know this information, but this is a minor privacy issue, as in reality very few users would set such preferences, and doing a wide search would incur a significant performance cost spinning up the worklets.

Debuggability
  • Shared Storage database contents for an origin can be viewed and modified within DevTools.
  • Shared Storage worklet can be inspected within DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All but WebView

Out of curiosity, why is WebView not supported for this?
 

Is this feature fully tested by web-platform-tests?
Yes

Finch feature name
SharedStorageAPIM125

Requires code in //chrome?
No

Estimated milestones
We intend to ship in M125.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5145686840705024

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41ee180b-5822-40fe-ac15-1bb1c9715e05n%40chromium.org.

Mike Taylor

unread,
Apr 19, 2024, 3:49:46 PMApr 19
to Yao Xiao, blink-dev

Would it be possible to write a paragraph on this specific change, i.e., what are the use cases this change addresses, and how does this help developers, etc.? Here in the thread is fine.

Josh Karlin

unread,
Apr 19, 2024, 3:56:55 PMApr 19
to Mike Taylor, Yao Xiao, blink-dev
On Fri, Apr 19, 2024 at 3:49 PM Mike Taylor <mike...@chromium.org> wrote:

On 4/19/24 12:52 PM, Yao Xiao wrote:

Contact emails

Would it be possible to write a paragraph on this specific change, i.e., what are the use cases this change addresses, and how does this help developers, etc.? Here in the thread is fine.


Sure thing. Shared Storage worklets are often run as third-party to a page. It's cumbersome to have to first create a x-origin iframe for the third-party, load a document, and only then get to start the worklet. This uses unnecessary resources and time. The primary purpose of this change is to make it possible to invoke a cross-origin worklet directly from the main frame of a page. It requires CORS and an additional opt-in header on the response header of the worklet script to do so.

 

Josh Karlin

unread,
Apr 19, 2024, 3:58:17 PMApr 19
to Vladimir Levin, Yao Xiao, blink-dev

Sorry, we should have specified that TAG, Gecko. and Webkit are negative on shared storage as a whole. So we did not ask for their opinion on this particular change.
 
 

Philip Jägenstedt

unread,
Apr 24, 2024, 11:49:00 AMApr 24
to Josh Karlin, Vladimir Levin, Yao Xiao, blink-dev
Hi Yao,

I see that https://github.com/WICG/shared-storage/pull/152 is still open, can that be landed before we ship this?

Also, can you point to the tests for this change?

Best regards,
Philip

Chris Harrelson

unread,
Apr 24, 2024, 11:50:50 AMApr 24
to Yao Xiao, blink-dev
On Fri, Apr 19, 2024 at 9:52 AM Yao Xiao <yao...@chromium.org> wrote:
Contact emails
Specification
https://wicg.github.io/shared-storage/

Additional anticipated specification changes
https://github.com/WICG/shared-storage/pull/152

Blink component
Blink>Storage>SharedStorage

Summary:
We plan to ship the following changes to the Shared Storage API:
  • selectURL() and run() will be exposed on the SharedStorageWorklet interface. When calling on the default scoped worklet (i.e. sharedStorage.worklet.selectURL()/run()), the behavior is equivalent to calling sharedStorage.selectURL()/run().
  • Users can create new worklets via const worklet = await sharedStorage.createWorklet(url, options). This API can be used to start multiple and potentially cross-origin worklets from a single document.
Hi, is it correct to say that these changes are purely ergonomic and don't expose any new capabilities?
 
--

Alex Russell

unread,
Apr 24, 2024, 11:52:06 AMApr 24
to blink-dev, Josh Karlin, Yao Xiao, blink-dev, Vladimir Levin
Hey Josh,

I agree that it might not be helpful to ping Gecko and WebKit on this, but it would still be helpful to update the TAG on how this design is evolving.

From that perspective, I would expect the TAG to request that we improve consistency by making cross-origin workers (not just worklets) possible. Where are we at on that?

Regards,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Josh Karlin

unread,
Apr 24, 2024, 1:20:29 PMApr 24
to Alex Russell, blink-dev, Yao Xiao, Vladimir Levin
On Wed, Apr 24, 2024 at 11:52 AM Alex Russell <sligh...@chromium.org> wrote:
Hey Josh,

I agree that it might not be helpful to ping Gecko and WebKit on this, but it would still be helpful to update the TAG on how this design is evolving.

Ack. I've updated the TAG thread.
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af749e5f-d3fb-4901-9427-f49efe95410cn%40chromium.org.

Josh Karlin

unread,
Apr 24, 2024, 1:48:39 PMApr 24
to Alex Russell, blink-dev, Yao Xiao, Vladimir Levin
Hey folks, I wanted to provide a bit more context on this change to help clarify the intention and any associated risks.

Today, when a third-party script runs on a page and wants to write data to shared storage, or use their shared storage data (e.g., create an aggregate report) under its own name, the script first needs to create a x-origin iframe and pass the data to that frame. This is because the origin used by shared storage is that of the context. This is cumbersome to the developer. They have to create an iframe document to listen for data (e.g., via name attribute, url query param, or postMessage) and act on that data (by writing to shared storage or starting a worklet). It's also terrible for resource usage and performance (the browser needs to navigate, load a document, and execute js).

The primary focus of this change is to allow a third-party on a page to invoke its own worklet (with access to its own storage) directly, bypassing the need to create a x-origin iframe. This is accomplished by allowing x-origin urls to be specified in a new API, `window.sharedStorage.createWorklet`. We are not changing the behavior of addModule, and we are not changing the capabilities of worklets. We're just making it easier to create x-origin worklets. In `createWorklet`, if a x-origin URL is specified, the response will require both `Shared-Storage-Cross-Origin-Worklet-Allowed: ?1` and CORS (Access-Control-Allow-Origin). That is, embedding a x-origin worklet is strictly opt-in. This is because a shared storage worklet has side-effects (e.g., sending reports, or selecting a url) which also consumes budget, and the worklet's origin may want to control who gets to use it. They should also (always a challenge on the web) take care to ensure that the data that they're receiving from the embedder is valid. 

Another useful aspect of introducing `createWorklet`, is that it allows a document to host multiple shared storage worklets and call methods on them individually. This makes it easier for pages that might have multiple teams creating them, that don't necessarily want to coordinate their shared storage worklet scripts. 

Best,

Josh

Chris Harrelson

unread,
Apr 24, 2024, 4:02:18 PMApr 24
to Josh Karlin, Alex Russell, blink-dev, Yao Xiao, Vladimir Levin
Thanks for the further explanation! It was very helpful.

LGTM1, but please make sure to land that open PR before shipping.

Yao Xiao

unread,
Apr 24, 2024, 8:46:00 PMApr 24
to Philip Jägenstedt, Josh Karlin, Alex Russell, blink-dev, Vladimir Levin, Chris Harrelson
Hi Yao,
I see that https://github.com/WICG/shared-storage/pull/152 is still open, can that be landed before we ship this?
The PR landed just now.

Also, can you point to the tests for this change?
Yes. cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html is a representative one. You can find other relevant tests in the same repository, by searching for "cross-origin".

Best,
Yao

Mike Taylor

unread,
Apr 25, 2024, 11:57:21 AMApr 25
to Yao Xiao, Philip Jägenstedt, Josh Karlin, Alex Russell, blink-dev, Vladimir Levin, Chris Harrelson

Yoav Weiss (@Shopify)

unread,
Apr 29, 2024, 4:43:33 AMApr 29
to Mike Taylor, Yao Xiao, Philip Jägenstedt, Josh Karlin, Alex Russell, blink-dev, Vladimir Levin, Chris Harrelson

Harley Li

unread,
May 14, 2024, 12:27:56 PMMay 14
to blink-dev, Yoav Weiss (@Shopify), Yao Xiao, Philip Jägenstedt, Josh Karlin, Alex Russell, blink-dev, Vladimir Levin, Chris Harrelson, Mike Taylor
Hello - wondering whether this cross-origin feature reflected in the demo website https://shared-storage-demo.web.app/ ? That is, not cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html because it still depends on Chromium's testing framework - currently we've run into problems when testing the API in DevTools Console, and we think the demo website could be of greater assistance. Thanks!

Yao Xiao

unread,
May 14, 2024, 5:51:18 PMMay 14
to Harley Li, blink-dev, Yoav Weiss (@Shopify), Philip Jägenstedt, Josh Karlin, Alex Russell, Vladimir Levin, Chris Harrelson, Mike Taylor
Hi Harley,

This is a demo site for the cross-origin worklet: https://shared-storage-cross-origin-worklet-demo.glitch.me

Yao

Reply all
Reply to author
Forward
0 new messages