Decide how to treat CSP sandbox in COOP

[shhnjk]

Any origin served with CSP sandbox (without allow-same-origin) will have opaque origin. But until that response header comes back, browser would not know its origin.

We should probably treat CSP sandboxed page as cross-origin even though the tuple of scheme, host, and port would match. But is it same-site or cross-site?

[annevk]

This is an interesting angle I had not considered. There is language that ensures a top-level browsing context with a non-empty popup sandboxing flag set is replaced by a network error if the response being navigated towards in that browsing context has COOP. This to ensure the sandboxing policy is not violated and the COOP policy (which expects a "clean" environment) isn't either.

You are asking what should happen if A navigates to A' where both have COOP, but the latter is also sandboxed via CSP. Currently those are not isolated from each other and would not result in a browsing context replacement. I think you're correct that this might be problematic as A' could do a timing attack on A. It's a little weird for A' to have COOP, but it's also not unreasonable to set that origin-wide.

cc @whatwg/security

[mikewest]

I think this is a question we'll need to answer in HTML. Do we process the CSP header before headers that make "same-site"/"same-origin" assertions, or after those headers?

Without thinking about it too hard, I think I agree with @shhnjk's suggestion that we'd process CSP first. It seems like a strong assertion from the server that it wants to reduce the privilege of a given file.

One consequence of that conclusion, though, worries me: it seems like we would need to apply the same logic to resources loaded into <iframe sandbox>, which means that pages would be unable to use both COOP/COEP and sandboxed frames at the same time. That doesn't seem like the right outcome. It should be possible for applications to drop their privilege.

@arturjanc might have some insight into Google application team's stance on this kind of question?

[annevk]

I'm not sure I understand the concern with <iframe sandbox>. Could you elaborate on the scenario?

(Apparently in Firefox the origin is computed earlier and CSP is taken into account as expected. I'm a little worried if we get other things that can manipulate origin it'll be hard to ensure they all do so at the right time, but perhaps that suggests this should have more dedicated infrastructure. Maybe #4926 helps.)

[mikewest]

I'm not sure I understand the concern with <iframe sandbox>. Could you elaborate on the scenario?

I think it was a mistake on my part; ignore me. I forgot that COOP doesn't affect frames, so it's still possible to use COOP, and load content into a sandbox. I'm dumb.

[arturjanc]

Taking the sandbox bit into account for the purposes of COOP seems slightly clearer (at which point the document should not be same-origin or same-site and should always create a new browsing context group), but I don't feel very strongly about either outcome from the deployment perspective. For instance if we kept the status quo, we could also ask the few places with sandboxed same-origin documents to not set COOP on such responses.

I am, however, a little worried about the scenario @annevk mentioned above where navigations from a sandbox document to a document with COOP would result in network errors. IIUC this would mean that e.g. links in user-uploaded files served as top-level sandbox documents will stop working when the target applications enable COOP. @annevk, could we instead force a new browsing context group on such navigations, or would that be insufficient?

[annevk]

I think that for a sandboxed top-level document its browsing context's popup sandboxing flag set is empty, unless it opens and navigates a popup. If we think that preserving sandboxing for popups continues to be important (I don't recall the rationale as to why we have it) I think we have to not let Cross-Origin-Opener-Policy be used to escape it. And at the same time, I don't think we want something that has Cross-Origin-Opener-Policy set to allowed to be sandboxed, so the only reasonable thing I could think of was a network error.

[arturjanc]

I think that for a sandboxed top-level document its browsing context's popup sandboxing flag set is empty, unless it opens and navigates a popup.

Does this mean that a sandboxed top-level document could navigate its own window to a document with COOP and it would succeed, but a popup to a document with COOP would result in a network error? If so, that seems like a reasonable trade-off -- also because IIUC it only affects sandboxed documents with allow-popups but without allow-popups-to-escape-sandbox. (I'm mostly trying to understand the compat risk and whether that would prevent developers from adopting COOP.)

[annevk]

Yeah, that's my understanding of how this works. A frame or a popup can be sandboxed (i.e., their browsing context), but you cannot sandbox an arbitrary top-level browsing context (unless it was created as a popup). In that case it's only the current document that's sandboxed.

[annevk]

I have made two edits related to sandboxing in https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e.

It now clearly acknowledges the issue from OP and suggests CSP ought to be taken into account when computing the origin of a response.

I also had to make adjustments to when a sandboxed popup becomes a network error due to https://bugzilla.mozilla.org/show_bug.cgi?id=1566868. To selectively quote from a comment there:

If a browsing context has a popup sandboxing flag set, it's a popup and it shouldn't be able to contain anything with a non-null COOP (note that Cross-Origin-Opener-Policy: unsafe-inherit might still work) as that would mean escaping the sandboxing, however mild that sandbox may be.

Then, if a browsing context swap happened due to unsafe-allow-outgoing not being set, the new top-level browsing context still ought to be sandboxed. So we need to copy the popup sandboxing flag set over. (The alternative would be for sandboxed environments governed by COOP without unsafe-allow-outgoing to not be able to open popups at all.)