Isolated Contexts spec review

[domfarolino]

@chrishtr asked me to take a look at the Isolated Contexts spec. After checking it out, here's some of the feedback I've come up with:

• Should other script directive values be used in https://wicg.github.io/isolated-web-apps/isolated-contexts#policy-sufficiently-mitigates-script-execution? I'm curious why unsafe-eval is not included when wasm-unsafe-eval?
• I don't think how the spec obtains a browsing context group from an environment settings object is valid. Top-level worker environment settings objects go through https://html.spec.whatwg.org/multipage/webappapis.html#obtaining-a-worker/worklet-agent which creates a new agent cluster that does not explicitly get added to a browsing context group's agent cluster map like they are for new window-agents. See Clarify "types of agent clusters" whatwg/html#6127 (comment) where I propose a future where all agents/clusters are explicitly owned by a BCG, so maybe to satisfy this point for now we can just add a red class=XXX box below this part of the spec here, mentioning that this link isn't quite clear until 6127 is fixed.
• This usage of "cross-origin isolated capability" is wrong. The spec says it is getting it off of a browsing context group, but it is pointing to an environment settings object's member.
• This line is a bit wrong. You should be using the "same origin" check instead of the unlinked word "equality". And you have to get "integrity origin" from somewhere (probably from |browsing context group|).
• This line is too vague. You should explicitly go from client -> global -> navigable -> browsing context group (this is just a rough sketch) using the various getters and members provided by HTML around navigables and BCGs. This is also subject to the same limitation mentioned earlier, about the client not always being associated with a BCG.
• Like before, prefer same-origin check in this line

Editorial feedback

• CSP directive values are linkable, but the spec does not currently link to them. For example, https://wicg.github.io/isolated-web-apps/isolated-contexts#csp-script-mitigation:~:text=%22%2C%20or%20%22%27-,unsafe%2Dinline,-%27%22. could link to https://w3c.github.io/webappsec-csp/#grammardef-unsafe-inline and probably should, to make things more clear
• Related, I would have https://wicg.github.io/isolated-web-apps/isolated-contexts#csp-subresources:~:text=s%20name%20is%20%22-,require%2Dtrusted%2Dtypes%2Dfor,-%22.%20%5BTRUSTED%2DTYPES link to https://w3c.github.io/trusted-types/dist/spec/#require-trusted-types-for-directive.
• "user agent defined" should be "implementation-defined".
• I would clearly enumerate the possibly return values of algorithms in their declaration, when they return static values like "foo" and "bar". Specifically https://wicg.github.io/isolated-web-apps/isolated-contexts#verify-the-integrity-of-a-response, for example.. See https://html.spec.whatwg.org/C#checking-if-unloading-is-canceled for example.

[domfarolino]

See whatwg/html#6127 (comment) where I propose a future where all agents/clusters are explicitly owned by a BCG, so maybe to satisfy this point for now we can just add a red class=XXX box below this part of the spec here, mentioning that this link isn't quite clear until 6127 is fixed.

Actually I think I take this part back given the more recent discussion on that thread. Since top-level worker environment settings objects can span multiple BCGs, there is no single BCG that an ESO can be relied upon associating with, so I think this part of the spec needs to be re-thought.

[robbiemc]

Thanks for reviewing it Dominic! I address most of your feedback in #43, but I'm still thinking through the BCG issue.

• Should other script directive values be used in https://wicg.github.io/isolated-web-apps/isolated-contexts#policy-sufficiently-mitigates-script-execution? I'm curious why unsafe-eval is not included when wasm-unsafe-eval?

No, the goal is to only load known scripts, which this achieves through forcing them into separate resources and integrity checking all resources. unsafe-eval or unsafe-inline would allow dynamic script injection/execution which would trivially bypass integrity checks. wasm-unsafe-eval is needed to get wasm to work at all, but doesn't introduce the same security issues as unsafe-eval because wasm has to proxy through js to access any capabilities. There's the possibility that the js bindings to the wasm blob could provide direct access to capabilities, but we consider that a similar threat to developers shipping a js interpreter in their app and using that to get eval, which we can't defend against from a purely technical level.