LGTM1. This seems like a good change for overall web consistency, and compat risks seem well-managed.
On Thursday, August 29, 2024 at 4:32:20 AM UTC+9 Cammie Smith Barnes wrote: > Intent to Ship: Shared Storage: Allowing Cross-Origin Script in addModule > & Aligning createWorklet > > Contact emailscam...@chromium.org, jkar...@chromium.org, > yao...@chromium.org, ashame...@google.com > Explainerhttps://github.com/WICG/shared-storage/blob/main/README.md > Specificationhttps://github.com/WICG/shared-storage/pull/161 > SummaryWe now allow sharedStorage.worklet.addModule to load cross-origin > script, while still using the invoking context's origin as the data > partition origin for accessing shared storage data. We also align the > behavior of sharedStorage.createWorklet, so that when it loads a > cross-origin script, it also uses the invoking context's origin as the data > partition origin by default (instead of using the script origin as it did > when initially implemented). Finally, to preserve the ability to use the > script's origin as the data partition origin, we introduce a new dataOrigin > option for createWorklet. > We have received feedback from developers stating they wanted to be able > to host and run their worklet script on a separate origin from the origin > that owns and writes their shared storage data. So we remove the > same-origin restriction for addModule. Note that, when the worklet script > is cross-origin to the invoking context, the invoking context's origin is > used as the partition origin for accessing shared storage. > To help avoid developer confusion in the long term, we align the default > behavior of createWorklet to use the invoking context's origin instead of > the script origin as its data partition origin. This is a breaking change, > but current usage of createWorklet is low as it was introduced in M125 and > those that are using it have upgraded to a forward-compatible incantation. > We also introduce a dataOrigin option that can be passed to use the > previous behavior. > > Blink componentBlink>Storage>SharedStorage > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3ESharedStorage> > TAG review & statusNotification of the change is here > <https://github.com/w3ctag/design-reviews/issues/747#issuecomment-2288670353> > but not expecting feedback as the entire Shared Storage feature is resolved > as unsatisfied. > > Risks > > Interoperability and CompatibilityThere are no interop risks as no other > browser has implemented shared storage. There is a compat risk for the > recently released createWorklet API. The worklet created by createWorklet > before this change had the data partition of the script’s origin. We’re > changing it, to align with addModule, to use the calling context’s origin > instead. We’re monitoring usage here > <https://chromestatus.com/metrics/feature/timeline/popularity/5007> of > the backwards-incompatible usage of the existing API and reaching out to > folks using it to let them know that they should make the following > forward-compatible change if they want the existing default behavior of > createWorklet to continue to function after this change: > before: sharedStorage.createWorklet(worklet_url);after: > sharedStorage.createWorklet(worklet_url, { dataOrigin: “script-origin” }); > The dataOrigin option will be ignored on browsers previous to this change, > and honored correctly after. > As of today, all users have switched to the forward-compatible incantation. > We are also monitoring usage of addModule with scripts that are > cross-origin to the calling context here > <https://chromestatus.com/metrics/feature/timeline/popularity/5028>, as > those will suddenly work when they did not before which could be surprising > to developers. As anticipated, this usage is extremely low (.00001% page > loads). > > Gecko: Negative on shared storage > WebKit: Negative on shared storage > Web developers: Positive, but there is follow-up work to allow > createWorklet() to serve the script from a different origin than the data > origin which is what folks ultimately want. That change will be > non-breaking. This work is a first step in that direction (allowing > addModule to be cross-origin). > Other signals: > WebView application risksDoes this intent deprecate or change behavior of > existing APIs, such that it has potentially high risk for Android > WebView-based applications?None > > DebuggabilityShared Storage worklets can be debugged in devtools. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?All but webview > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?Yes > Flag name on chrome://flagsNone > Finch feature nameSharedStorageCrossOriginScript and > SharedStorageCreateWorkletUseContextOriginByDefault > Non-finch justificationNA > Requires code in //chrome?False > Estimated milestonesM130 > > Anticipated spec changesNone > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/6531477832204288?gate=6576220452683776 > Links to previous Intent discussionsIntent to Prototype: > https://groups.google.com/a/chromium.org/g/blink-dev/c/YZ4XGewKVuk/m/v8CwKfq8AAAJ?utm_medium=email&utm_source=footer > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- 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/a3c65cdb-a26a-4914-9787-bab33ca58b85n%40chromium.org.
