cam...@chromium.org, jka...@chromium.org, yao...@chromium.org, asha...@google.com
https://github.com/WICG/shared-storage/blob/main/README.md
https://github.com/WICG/shared-storage/pull/161
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.
https://github.com/WICG/shared-storage/pull/158
None
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.
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:
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
Not yet
None
SharedStorageCrossOriginScript
None
False
M129
https://chromestatus.com/feature/6531477832204288
This intent message was generated by Chrome Platform Status.