[worklets] Restrict worklets to same-origin

[annevk]

See whatwg/fetch#527 (comment) by @wanderview. This would allow us to make worklets proper clients.

cc @jakearchibald @jungkees @mikewest

[annevk]

cc @padenot @hoch

[hoch]

I don't see a solid "conclusion" or "agreement" in the thread above. However, perhaps starting from same-origin restriction and expanding to cross-origin later sounds reasonable to me.

Is there any action time here for Web Audio API spec?

[bfgeek]

I'm slightly confused from the other thread:

This issue seems to be about how this would integrate with the service workers Clients.

From @wanderview

Wait, don't worklets create globals? Is there any precedent for a subresource that creates globals? This would seem to make the top level entities to me.

The sub-resource request via addModule doesn't create a new global. They just get invoked and run in the same global as everything else.

From @annevk

They're not same-origin in the sense needed to be clients. That's what @wanderview was after.

But they are? My understanding at least is that a Client here would just be the Worklet object which is already same origin (it is tied to its owning document). This can request sub-resources (via. addModule) and invoke it into that scope, right?

[wanderview]

I've looked at the spec some more. The worklet global is currently spec'd to be an opaque origin. So this issue probably doesn't make too much sense.

Also, the spec is written such that the worklet does not fetch its own module scripts. This is done by the owning document.

So its ok to treat the worklet global as a proper client. It just has an opaque origin and no one can see it via the Clients API. It also isn't controlled by a service worker, but thats ok too since it doesn't do any fetching itself.

I think this can probably be closed. (At least from my perspective.)

Sorry for the confusion.

[annevk]

@bfgeek Worklet isn't what I'd call the client. It might represent it in some fashion, but the client is much closer to the global object.

I'm fine with worklets being subresources though, though I don't think that should mean that dedicated workers should become that too. See whatwg/html#3109 and whatwg/html#3112 for that discussion, which @domenic wants to tie to this one...

[wanderview]

Right, so far Client has been designed to map one-to-one with a global in the system. If a worklet can create N globals, then there will be N Clients. Of course, you can only observe Client objects same-origin, so the worklet globals would not be observable since they have an opaque origin.

[domenic]

Is this issue still valid? I'm unsure how to proceed here...

[annevk]

I don't think worklets can be clients as they are not resource-derived. So their client must be the document that created them.

[domenic]

Closing then; see also some IRC discussion in https://freenode.logbot.info/whatwg/20201019#c5510723