Intent to Prototype: Shared Storage API enhancement (allow cross-origin script in addModule & align createWorklet)
Cammie Smith Barnes
Contact emails
cam...@chromium.org, jka...@chromium.org, yao...@chromium.org, asha...@google.com
Explainer
https://github.com/WICG/shared-storage/blob/main/README.md
Specification
https://github.com/WICG/shared-storage/pull/161
Summary and Motivation
We have received feedback from developers stating they wanted to be able to host and run their worklet script on a separate origin (e.g., a cdn) from the origin that owns and writes their shared storage data. Therefore, we’re removing the same-origin restriction for addModule worklet scripts. Note that, when the worklet script is cross-origin to the invoking context, the invoking context's origin is still used as the partition origin for accessing shared storage.
We also made a second change, which is to align the new sharedStorage.createWorklet API (shipped in M125) with addModule to use the calling context’s origin as the data origin by default (instead of the script’s origin as the data origin). This is a breaking change, and we discuss our mitigations below.
Blink component
Initial public proposal
https://github.com/WICG/shared-storage/pull/158
TAG review
None
TAG review status
We asked if they’d like to see follow-up changes to shared storage given its unsatisfied status, and have not received a response. We take the lack of response as a signal that they would not like to be made aware of subsequent changes.
Risks
Interoperability and Compatibility
There 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 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.
We have created a use counter for usage of createWorklet without the forward-compatible dataOrigin option so that we will know when it’s safe to make this change. We are also monitoring usage of addModule with scripts that are cross-origin to the calling context here, as those will suddenly work when they did not before which could be surprising to developers.
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
Debuggability
None
Is this feature fully tested by web-platform-tests?
Not yet
Flag name on chrome://flags
None
Finch feature name
SharedStorageCrossOriginScript
Non-finch justification
None
Requires code in //chrome?
False
Estimated milestones
M129
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6531477832204288
This intent message was generated by Chrome Platform Status.