Restrict communication between same-origin documents in different pages with different COOP status

[camillelamy]

COOP was introduced with the goal of allowing browsers to provide greater isolation to pages even when browsers do not have Site Isolation. With the state of the spec, we are able to deliver this for COOP same-origin-plus-coep. Addressing #6177 should allow isolation of COOP same-origin pages. We would also like to provide greater isolation to COOP same-origin-allow-popups pages.

To do this we first need to address #6177. However, we would also need to make same-origin documents embedded in pages with different COOP status behave as cross-origin documents. Let's consider the case where a COOP same-origin-allow-popups on origin A embeds a subframe of origin B. This cross-origin popup opens a popup to page B with COOP unsafe-none. In a browser without Site Isolation, the top-level document A and its subframe B have to be placed in the same process. When the cross-origin iframe opens the page B, because they are same-origin, the browser has to put it in the same process as the iframe, which is page A's process. This is the exact same behavior as if A's COOP was unsafe-none. If subframe B and popup B were considered cross-origin for the purpose of communication because they are in pages with different COOP status, the browser could put them in different processes. This allows to key processes to COOP status and top-level origin when a page sets any COOP higher than unsafe-none.

We believe that this is a reasonable trade off for pages to protect themselves against Spectre. Pages would gain the same process-isolation as with COOP same-origin or same-origin-plus-coep, while preserving access to cross-origin properties on an opened popup. COOP same-origin-allow-popups was introduced to give pages extra security while allowing cross-origin OAuth flows to still work, and we believe this change would allow to do just that.

cc @annevk @domenic

[domenic]

This seems pretty radical; so far we've worked hard to preserve the invariant that same-origin documents are treated as same-origin to each other. (E.g., in designing the origin isolation feature.)

I'm interested in what "cross-origin for the purposes of communication" means specifically, and whether it's different than just "cross-origin". The allusion to processes imply that maybe this is about synchronous access, so that'd mean, accessing each others' DOM, plus postMessage()ing of WebAssembly.Memory and SharedArrayBuffer objects? But I guess it would not impact things like muting cross-origin script errors, or autofocus processing models, or X-Frame-Options: sameorigin, or anything at the fetch layer?

[camillelamy]

You're correct, we are concerned about synchronous access here. So essentially DOM manipulation and access of non-crossOrigin WindowProxy properties.

One thing to note is that both documents have to be in different windows to have different COOP status. So things like X-Frame-Options don't apply, same IIUC for autofocus.

For script errors, we wouldn't want to change the behavior.