Expose COOP and COEP state to JavaScript

[annevk]

As @kripken points out in https://twitter.com/kripken/status/1167225879488954369 using postMessage() for feature detection (see also #4732) is less than ideal as in the success case it'll generate a message event.

(You could create an <iframe>, but that seems ungainly. You could also create a MessageChannel, except that doesn't work well across browsers and is not likely to be solved soon.)

Idea:

• window.crossOriginOpener, returns the empty string, "same-origin", "same-site", "same-origin unsafe-allow-outgoing", or "same-site unsafe-allow-outgoing".
• self.crossOriginEmbedder, returns the empty string or "require-corp".
• self.isolatedAgentCluster, returns true if the first returns "same-origin" and the second "require-corp"; otherwise false.

(window. only exposed on Window, self. on WindowOrWorkerGlobalScope or potentially something that includes worklets as audio worklets will need this too.)

cc @mikewest @arturjanc @rniwa @othermaciej @domenic

[rniwa]

@cdumez

[domenic]

My only comment is we should be careful about adding user-facing APIs using new terms that don't appear elsewhere for web developers.

I think "embedder" is probably already in some public APIs, but "agent cluster" is definitely not.

[annevk]

That's fair, I'd also be fine with crossOriginIsolated and that has the benefit of matching the other names.

[annevk]

I've added self.crossOriginIsolated to #4734. I think that's good enough for the initial launch of this feature and the others can be added if there's demand.

[annevk]

Bugs:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1591892
• https://bugs.chromium.org/p/chromium/issues/detail?id=1018680

[mikewest]

crossOriginIsolated sounds fine as a first pass to me. Thanks!

[domenic]

I've learned a bit more about this problem space and I think it might be worth some last-minute bikeshedding on the name. To be clear, I am OK with crossOriginIsolated as the plan of record, but while we still have some time, let's dig in a bit more.

In particular we have two types of isolation coming down the pipe:

• COEP + COOP, which ensure that everything in your agent cluster has explicitly allowed itself to be put there. Part of the mechanism for doing so is by moving popup agents into separate browsing context groups, which have their own agent cluster maps.

• Origin isolation, which prevents you from sharing memory or synchronously scripting same-site-cross-origin pages. The mechanism for doing so is to change a given browsing context's group's agent cluster map to be origin-keyed.

These are both valuable and complementary. I want to check though that the names are good. In particular, we appear to be headed toward a world where we bill these to developers as "cross-origin isolation" and "origin isolation". E.g. one could imagine self.crossOriginIsolated as well as self.originIsolated. Is that too confusing?

I'm definitely open to renaming the origin isolation proposal if that would be helpful. Perhaps it could be something more like "memory sharing isolation" or "same origin-only memory sharing"? (Those kind of assume that "non-shared memory" implies "cannot synchronously script each other", which may not be obvious...)

[annevk]

I realized that origin isolation is only relevant for window agents (see WICG/origin-agent-cluster#4), perhaps that can lead to a clearer name? It's also not immediately clear we'd need to expose the API in shared/service workers as they are scoped by origin (well, they're really scoped by identity, which is arguably even better) by definition. COEP on the other hand does apply everywhere, and requires COOP in addition for window agents. (Aside: in Firefox we'll likely roll out COOP+COEP support before COEP in shared/service workers.)

[annevk]

See #5122 for a new idea around COOP+COEP and origin isolation.

I think keeping crossOriginIsolated as the name here is still good though given the names of the headers involved.

[annevk]

Folding this into #4732.