COOP same-origin and same-origin-allow-popups should key agent clusters to origin even without COEP

[camillelamy]

When COOP and COEP are enabled, the page is crossOriginIsolated. This has an impact on agent clusters in https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-cluster-formalism:bcg-cross-origin-isolated.

Just setting COOP same-origin or same-origin-allow-popups should have the same impact. COOP has a whole was designed with separation by origin instead of site in mind, so it makes little sense for a COOP page to have its agent clusters keyed on site rather than origin. Keying on origins would also allow browsers to better isolate COOP pages against Spectre-like attacks, even without the presence of COEP. This provides additional security to websites that adopt COOP even without COEP.

cc @domenic @annevk

[annevk]

The reason we required COEP is to ensure there is consent from nested documents on this difference in keying, right? And same-origin-allow-popups would allow you to impact non-consenting popups.

[domenic]

Yeah, @annevk's reasoning matches what I recall.

In general, allowing embedders/openers to control what embeddees/opened windows do is a bit scary, as it gives them a degree of control over cross-origin content which could be used maliciously. There are historical exceptions, e.g. <iframe sandbox>, but modern embeddee-control features like document policy and CSP embedded enforcement seem to require consent.

We could make the case that it's OK to allow embedders/openers to break embeddees/opened windows, if "break" means "stop from using document.domain and postMessage()ing WebAssembly.Modules cross-origin". That would make this part of a general document.domain deprecation plan (/cc @mikewest).

I'll note that we previously made a similar decision when introducing the "document-domain" feature policy, although I believe that is now being moved to a document policy (which requires embedder consent).

[camillelamy]

I would argue that COOP same-origin already breaks embeddees' opened windows. When you set COOP same-origin, any cross-origin document that opens a popup opens it with rel no-opener, whether they set it themselves or not. And there is no mechanism for them to give consent to that. If we are concerned about iframes being broken by their COOP embedders, which again already happens today, maybe we should give them a way to opt out of being embedded in a COOP pages.

In terms of actual breakages, what I am interested in forbidding is document.domain and postMessage()ing WebAssembly.Modules cross-origin. I was under the impression that keying agent cluster on origin was how you accomplish that in html spec, but maybe I am mistaken. And yes, this is clearly in line with a longer term wish of deprecating this for all websites (but there are less users of COOP right now, so it is easier to achieve).

In any case, I think it is reasonable at least for the document that sets COOP same-origin* to not have access to document.domain. Since its origin is going to be used in browsing context switch decisions, it would be very weird if it can change. And we can work reasonable isolation if the top-level COOP document origin is not going to change.

[annevk]

Popups are not guaranteed and also sit behind user activation, but fair. Perhaps Cross-Origin-Opener-Policy can be a superset of Origin-Isolation? That way it does not affect isolation of cross-origin children, but it does impact its own origin.

[camillelamy]

It's not just popups though. Basically any window.open from a cross-origin subframe is subject to rel no-opener, and I don't think that sits behind user activation.

[annevk]

Those are all considered "popups" and they do. (Edit: for clarity, they are all auxiliary browsing contexts, only some get rendered as popups, but that distinction is not yet defined by HTML and doesn't matter here.)

[domenic]

In terms of actual breakages, what I am interested in forbidding is document.domain and postMessage()ing WebAssembly.Modules cross-origin. I was under the impression that keying agent cluster on origin was how you accomplish that in html spec, but maybe I am mistaken.

You're correct; origin-keying is the right way to achieve this. It's just a matter of whether it's OK to break other page's usage of these features without their consent.

To be clear, I am on the side that thinks that's OK. These are bad legacy features, and I think we should be OK breaking them. But security folks have been against such breakage in the past. As you point out, they were OK with COOP, so maybe this is just a step further.

From another point of view: I suspect you are representing Chrome security folks on this :). So the main operative question is how other browsers want to weigh allowing embedders/openers to break embeddees/openees, vs. increasing isolation and disabling bad legacy features.

In any case, I think it is reasonable at least for the document that sets COOP same-origin* to not have access to document.domain. In any case, I think it is reasonable at least for the document that sets COOP same-origin* to not have access to document.domain. Since its origin is going to be used in browsing context switch decisions, it would be very weird if it can change. And we can work reasonable isolation if the top-level COOP document origin is not going to change.

That seems very reasonable indeed, but it would be conceptually cleaner if we can go all the way to origin-keying. Let's keep this in mind as a fallback position though!

Perhaps Cross-Origin-Opener-Policy can be a superset of Origin-Isolation?

What do you mean by this, exactly?

In implementations, this might not be desirable, as origin-isolation is a stronger "I would benefit from my own process" signal than COOP is.

In specification land, do you mean that COOP would reuse the consistency mechanism of the historical agent cluster key map?

That way it does not affect isolation of cross-origin children, but it does impact its own origin.

I'm not clear how the proposal in the OP would affect isolation of cross-origin children...

[annevk]

Cross-origin isolated is for all the agent clusters in a browsing context group. Origin isolation is for a specific agent cluster. OP seems to be talking about the former. The latter seems more reasonable.

[camillelamy]

For the purpose of isolation, we only need the agent cluster for the top-level frame to be keyed to origin. So if we take that as meaning that COOP implies origin isolation for the top-level origin, in as much as it has the same web observable effects of origin isolation, this is fine. However, we do not want to mean origin isolation as a suggestion to the browser to create processes based on origin as a boundary instead of site. Does that make sense?

[annevk]

Sure, but since that hint is really up to the browser and an implementation detail in a way, I think they should use the exact same infrastructure specification-wise.

[domenic]

We probably want to reflect the strength of the process-allocation hint in some non-normative text, and it might be best to do so closer to agent cluster allocation than back in the sections defining the OI and COOP headers. But I agree the normative infrastructure could (and probably should) be exactly the same.

More concretely: we could just thread things through so that appropriate COOP values ensure requestsOI is true in https://html.spec.whatwg.org/#obtain-similar-origin-window-agent . At that point we'd then add something like

Note: if requestsOI is true due to OI, then this indicates the website believes it would benefit from isolation for performance purposes, and thus it might be a good idea to allocate a new process. Whereas if requestsOI is true due to COOP, no such hint was given.

(needs a bit more wordsmithing).