COOP + non-HTTP non-initial-about:blank inheritance

[annevk]

Part of this is tracked by #5168 where I think we have good solutions for initial about:blank. #4916 tracks this for COEP.

data: cannot work as it's not a secure context.

about:blank and blob: remain for popups. I think we should inherit for them as we do normally, presumably from the source browsing context document.

Work in progress tests:

• HTML: COOP+COEP blob URL popup web-platform-tests/wpt#19947
• HTML: COOP and a blob URL popup that popups web-platform-tests/wpt#19949
• HTML: top-level data: URLs web-platform-tests/wpt#17730 (forbidding navigation to top-level data:)

cc @clelland @zcorpan @jugglinmike @ParisMeuleman @mikewest @hemeryar

[annevk]

The big problem with defining the exact model for blob: URLs (@zcorpan asked in web-platform-tests/wpt#19947 (comment)) is that the existing model for them is not defined.

In particular:

• Navigation to blob URLs w3c/FileAPI#145 references Should fetches to blob URLs be more restricted? fetch#666 which details that when navigation succeeds for blob: URLs is not defined.
• It also references Put policies in the blob URL store w3c/FileAPI#142 which could be a model for how we copy COOP state, though consider:
  • Browsing context group A with document A1 with COOP creates a blob: URL blobURL.
  • Browsing context group B with document A2 without COOP receives blobURL via BroadcastChannel or some such and opens it in a popup.
  • Do we get a browsing context group C? Is that what we want? (The existing model is probably that you copy state from the source document, but this has certain issues when the user copy-and-pastes blobURL. Those issues do not have to apply to COOP however (but do apply to COEP) as we could always COOP when the user enters a URL.)

cc @hiroshige-g @mkruisselbrink

[annevk]

@whatwg/cross-origin-isolation please see w3c/webappsec-secure-contexts#69 for some further thoughts on data: URLs.

[annevk]

Blob URL scenarios:

• BCG1 (browsing context group)/D1 (document) without COOP+COEP creates a blob URL and hands it to BCG2/D2 with COOP+COEP. Can D2 use it for a dedicated worker? Current browsers: probably yes. Proposed blob URL setup: probably no?
• BCG1/D1 with COOP+COEP creates a blob URL and hands it to BCG2/D2 without COOP+COEP. D2 creates a shared worker. Does it have COOP+COEP? Current browsers: probably no. Proposed blob URL setup: probably yes?

I think the proposed changes are good and they are also likely web-compatible given how esoteric things are, but we might have to tweak things, depending.

[yutakahirano]

Does that apply when the URL is persisted to a storage?

[annevk]

The blob URL? I would expect the lifetime of its associated blob in the blob URL store to not outlive the global that created it. https://w3c.github.io/FileAPI/#url states this as fact, but does not in fact require it.

[yutakahirano]

Ah I see thank you.

[annevk]

Update on data: URLs. They cannot be navigated to in top-level browsing contexts so it's mostly moot, but we haven't exactly enforced that fully. I think if user agents do allow navigation to them in a top-level browsing context they should always ensure that it's a fresh browsing context group, especially if the creator is from a COOP browsing context group.

[ParisMeuleman]

I (re)came across this while exploring the addition of COOP to the PolicyContainer within Chromium and the behavior we expect for the local schemes, specifically "about:blank" as the initial empty document and data are already covered.
Note that this seems to really matter only in the COOP:same-origin-allow-popup mixed with popups having COOP: unsafe-none cases.
Current Chromium behavior (and my understanding of the spec following a short discussion with Camille) is to keep the previous documents' policy, this seems an odd behavior, I'd expect to inherit from the document that initiates the navigation.

My understanding is that's what you are suggest here about:blank and blob: remain for popups. [...] inherit as we do normally, presumably from the source document., assuming that the source document is associated to the navigating across documents spec source browsing context, i.e. the document responsible for starting the navigation.

I would suggest however that we mimic the behavior of the initial empty document instead:
inherit from the source document top level document if they are both same-origin, unsafe-none otherwise.
Indeed, unless I misunderstood, we don't inherit to child frames, nor do they process COOP from response headers.

[annevk]

Yeah that sounds reasonable and I guess that's also what we want for blob: URLs created in a nested document, right? (Assuming we successfully migrate to the model where we store their policy at creation time.)

[ParisMeuleman]

yes I think that would be the desired behavior for blob: as well, with the provided assumption.

[ParisMeuleman]

One thing I did not mention though is switching the browsing context group due to that navigation to those local schemes in some conditions:

• Tab 1, with top frame's A being same-origin-allow-popups
• A opens B, the response has COOP:unsafe none
• B's document stays in the same browsing context group thanks to same-origin-allow-popups behavior
• A navigates B to about:blank
• B's document would be in a different browsing context group since it navigated from a COOP:none to a COOP:same-origin-allow-popups document.

This seems the correct behavior to me and is identical to what would happen if B was navigated to a page that is same-origin with A and had COOP - same-origin-allow-popups.
Could switching the browsing context group be a problem for local schemes?

[annevk]

I think that is fine as it would also happen if you navigated B to another A. The weird thing might be that it'll be a (useless) blank document, but I don't see a reason to add a special case for that. User agents might want to show this as some kind of error to end users? Not sure.

[ParisMeuleman]

Sound good, and I don't think there's any reason to display an error.