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 <https://github.com/WICG/shared-storage?tab=readme-ov-file#proposed-api-surface>`. 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 <https://github.com/WICG/shared-storage?tab=readme-ov-file#proposed-api-surface>`, 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 On Wed, Apr 24, 2024 at 1:19 PM Josh Karlin <jkar...@chromium.org> wrote: > > > On Wed, Apr 24, 2024 at 11:52 AM Alex Russell <slightly...@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 > <https://github.com/w3ctag/design-reviews/issues/747#issuecomment-2075450880> > . > > >> >> 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 >> >> On Friday, April 19, 2024 at 12:58:17 PM UTC-7 Josh Karlin wrote: >> >>> On Fri, Apr 19, 2024 at 1:59 PM Vladimir Levin <vmp...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao <yao...@chromium.org> wrote: >>>> >>>>> *Contact emails* >>>>> cam...@chromium.org >>>>> jkar...@chromium.org >>>>> yao...@chromium.org >>>>> rohitgu...@google.com >>>>> ashame...@google.com >>>>> >>>>> *Explainer* >>>>> https://github.com/WICG/shared-storage >>>>> >>>>> *Specification* >>>>> https://wicg.github.io/shared-storage/ >>>>> >>>>> *Additional anticipated specification changes* >>>>> https://github.com/WICG/shared-storage/pull/152 >>>>> >>>>> *Blink component* >>>>> Blink>Storage>SharedStorage >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage&can=2> >>>>> >>>>> *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: >>>>> >>>> >>>> Is it possible to file position requests? (https://bit.ly/blink-signals >>>> ) >>>> >>> >>>> Was there a TAG review filed for this as well? >>>> >>> >>> >>> 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. >>> >>> >>> >>>> >>>> >>>>> >>>>> *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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> 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+unsubscr...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41ee180b-5822-40fe-ac15-1bb1c9715e05n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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+unsubscr...@chromium.org. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O7c2%2B%2B12PtuAS%2BSfHx0%2B8X6SuA7mr6saW%3DRVhewXkUHw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O7c2%2B%2B12PtuAS%2BSfHx0%2B8X6SuA7mr6saW%3DRVhewXkUHw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af749e5f-d3fb-4901-9427-f49efe95410cn%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaPuu4frRrmLq01eAsTAb2fMnQ_rZ3OJoz9dWd%3DVfQQBhA%40mail.gmail.com.
