Explainer: Allow cross-origin script in addModule & align createWorklet

[pythagoraskitty]

Currently, addModule only allows same-origin script. This was for convenience of the initial implementation, however, and is no longer necessary.

The worklet standard does not contain this restriction. In fact, we have received feedback from developers stating they would like to be able to host and run their worklet script on a separate origin---say a CDN---from the origin that owns and writes their shared storage data.

So we update the explainer to remove the same-origin restriction for addModule. We also 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.

Since createWorklet already allows cross-origin scripts, but currently uses the worklet script's origin as the data partition origin, updating addModule as described above without also making a change to createWorklet is liable to cause developer confusion in the long term.

We have therefore decided to align createWorklet's default data partition origin with addModule's. createWorklet will use the invoking context's origin by default. This is a breaking change, but current usage of createWorklet is low as it was just introduced in M125.

To preserve the ability to create a worklet whose script is cross-origin to the invoking context and then run operations on the worklet script origin's shared storage data, we introduce a new dataOrigin option for createWorklet. Passing dataOrigin with "script-origin" as its value will designate the worklet script origin as the partition origin for shared storage. For now, "script-origin" and "context-origin" will be the only allowed values for dataOrigin, when used. We’re considering adding support for separate data and script origins for createWorklet in the future.

A corresponding specification update will follow.

[dmdabbs]

If a publisher allows some partner to use SharedStorage via the policy-controlled feature, is there a way to restrict the partner's data access?

[dmdabbs]

Will the new dataOrigin capability be feature-detectable?

[pythagoraskitty]

If a publisher allows some partner to use SharedStorage via the policy-controlled feature, is there a way to restrict the partner's data access?

The publisher/embedder can control which origins have access to Shared Storage via the Permissions Policy, yes. The origins allowed to use the policy-controlled feature "shared-storage" are those that will have permission to be used as data origins for the Shared Storage API.

Will the new dataOrigin capability be feature-detectable?

You will be able to detect it if you call createWorklet() with a valid same-origin worklet script as the source but an invalid value passed to "dataOrigin", e.g. something like

let dataOriginOptionDefined = false;
try {
  await sharedStorage.createWorklet("dummy-worklet.js", {dataOrigin: "invalid"});
} catch (e) {
  if (e.message.includes("dataOrigin")) {  // or some other check to help distinguish it from other possible errors
    dataOriginOptionDefined = true;
  }
}

We haven't implemented this yet, and the exact error message/type haven't been determined yet. So the above snippet is subject to change (and I didn't test it), but something along these lines should work.