Raise the bar for SharedArrayBuffer via postMessage()

[annevk]

This depends on the work to add Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy. It specifies how postMessage() is affected when both those headers are set for the agent clusters they impact.

Closes #4732.

• At least two implementers are interested (and none opposed):
  • Firefox
  • Google
• Tests are written and can be reviewed and commented upon at:
  • Web Audio: SharedArrayBuffer and COOP/COEP web-platform-tests/wpt#17719
  • HTML: BroadcastChannel and SharedArrayBuffer success case revamp web-platform-tests/wpt#17760
  • HTML: SharedArrayBuffer infrastructure adjustments web-platform-tests/wpt#17761
  • HTML: ensure serializing SharedArrayBuffer throws without COOP+COEP web-platform-tests/wpt#17802
  • HTML: cross-site SharedArrayBuffer ought to not work web-platform-tests/wpt#17909
  • HTML: COEP and ImageBitmap web-platform-tests/wpt#18543
  • Basic crossOriginIsolated tests web-platform-tests/wpt#20116
  • SharedArrayBuffer constructor is not always exposed web-platform-tests/wpt#22358
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1477743
  • Safari: …

(See WHATWG Working Mode: Changes for more details.)

---

/browsers.html ( diff )
/origin.html ( diff )
/structured-data.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )

[annevk]

I've updated OP with a number of tests of which some are landed. I made the decision to land test changes as this is a large undertaking that has multi-implementer buy-in and landing it all at once would it a lot more likely we'd miss important things. The changes should minimally disrupt existing coverage. I'll try to continue to keep OP up-to-date.

[annevk]

I would be okay with the [SecureContext] restriction. I don't think Firefox currently has that, but we could add it. On the other hand it might be useful to have available always as then you don't need to check isSecureContext first.

[domenic]

Sorry, but I think this will need rebasing now that 0221df8 got merged. I'll try to review anyway.

I asked around internally for [SecureContext] and @arturjanc seemed slightly in favor of exposing it in non-secure contexts. I'm torn; [SecureContext] seems a bit more logical since the whole feature is restricted to secure contexts, but maybe we should make an exception for feature-detection getters. (And then there's the whole line of thinking that all new APIs should be [SecureContext], heh...)

I do think the equivalent getter for origin isolation should follow whatever pattern we choose here.

[domenic]

It's not clear to me whether this will ever be possible. Fetches require fetch clients (ESOs). So we need to create the ESO/realm/global object before doing the fetch. And we should put all realms into agents, so we need to create the agent and its corresponding agent cluster before the fetch.

I think this is OK as-is, and we should delete the XXX. It seems similar to how various properties of the WorkerGlobalScope (and thus, the values returned by the ESO algorithms) are only set after the fetch. It's OK, as long as no code runs.

[annevk]

Why wouldn't it use outside settings? Note that for security reasons browsers would not be able to implement this approach as it would not properly process-isolate the worker (using a cross-origin isolated process that is).

[domenic]

You're right; the fetch client is outside settings. Ugh, this would be a painful redesign; we'd need to split up fetching the scripts (doable before creating the global) from creating the scripts (doable only after the global exists). Alright, this XXX should stay, I concede.

[domenic]

It would be particularly bad for modules, because parsing requires a realm to exist, but you need to parse before you can continue fetching dependencies. So we'd need to split it up into something like

1. Fetch top-level source text. (Technically all we need are the headers.... maybe stop at getting the response.)
2. Create the realm
3. Create top-level script
4. Fetch and create dependency scripts

Funnnnn.

[annevk]

I squashed and then rebased and there were no issues. Somewhat strange. I'll work on some fixups now.

[domenic]

LGTM with nits, hooray

[annevk]

Oh wait, given the wording in tc39/ecma262#1903 I guess it's solely up to the host, not the implementation. So this is all good.