“Report a violation” can seemingly reach “fire an event at” w/ WorkletGlobalScope

[bathos]

The value of a WorkletGlobalScope.[[Realm]].[[HostDefined]] environment settings object’s policy container’s CSP list is a copy of the (walking backwards now:) CSP list of the policy container of the ESO of the Realm Record of the Worklet whose global scopes list it’s being uniquely appended to.

Most CSP directives have no effect in a Worklet environment given they’re designed for narrow purposes that benefit from “stateless” execution at the browser’s discretion. There are no built-ins exposed that can kick off new fetches in them and a dynamic import expression will evaluate to an immediately rejected Promise. But:

1. The addModule algorithm hits fetch a worker script graph. A shared module graph with special fetch steps is shared by every WGS, but the fetch client settings object passed here is that of the WorkletGlobalScope. The steps from there are not exactly easy to follow, but as far as I can tell, you’re able to end up hitting Should request be blocked by Content Security Policy? with the environment settings object of the WorkerGlobalScope in tow.
2. Unlike the dynamic import case, nothing special happens when Worklet code hits the HostEnsureCanCompileStrings host hook. If eval isn’t permitted by the CSP list, you’d end up in EnsureCSPDoesNotBlockStringCompilation as usual and the realm will be WorkletGlobalScope.[[Realm]].
3. If the Trusted Types & Dynamic Code Brand Checks proposals are implemented (as they are in Chromium) and if the CSP list is enforcing a Trusted Types policy, then even if eval is permitted, you’re guaranteed to bottom out early in the modified EnsureCSPDoesNotBlockStringCompilation if you use eval sinks because none of the Trusted Types API’s constructs’ exposure sets include Worklet. You just don’t got em!*

For any of those paths we next end up in Report a violation, where target will be set to the WorkletGlobalScope at 3.2. Then it wants to Fire an event at target ... but it isn’t an EventTarget and [undefined behavior] ensues.

Should probably go w/o saying, but especially in this case given there are some pretty byzantine/subtle inter-spec code paths involved, I could easily be missing something along the way. I’m also not sure whether, if I am correct, the remedy would be here or in HTML / Fetch / all three, but since this is where it’s most specifically relevant subject-wise it seems like the best starting point.

---

* Though you could maybe narrow the CSP with trusted-types directives after kicking off the worklet given the CSP list gets cloned? — i.e. it’s not a “live” connection to the original CSP list, it’s an instantiation-time snapshot. 🤔... and if I’m following this right, I think the original list is getting cloned for each new WGS instance. The browser is supposed to be able to do that at-will on or off the main thread unobservably. Given the original CSP list is mutable state of another realm / agent, there may be something off there.

[antosart]

I am wondering. Should we fire the event on the parent document in the case of worklets?

[annevk]

Not in general as that creates a communication channel. It might be acceptable for audio worklets.

cc @domenic @padenot

[domenic]

The easy fix is just to have "report a violation" test if target is an EventTarget. I suspect that is what implementations do?

[antosart]

The easy fix sounds fine. But then for the same reason we should also skip POSTing a violation (that's also a communication channel, since the violation is sent to the parent document's report-uri endpoint)?

[annevk]

Yeah I think so. Non-audio worklets are not supposed to be able to fetch.

[antosart]

I think this is fixed by #549.