/cc @camillelamy

It seems a bit unfortunate that the header starts with Cross-Origin-*.

Also, I find omit rather vague given the current values. Are popups allowed for instance?

Also, I find omit rather vague given the current values. Are popups allowed for instance?

Maybe "noopener" would be a better value. From my perspective, popups should be allowed, as long as they have their opener relationship severed.

I think I understand what you mean, but that's a confusing comment given the current set of values. As in, same-origin-allow-popups explicitly does not break the relationship with any popups. It only breaks the incoming cross-origin relationship, if any.

To date we have only used noopener for outgoing relationships, but it might still be reasonable.

I think the other bit that's missing here is some kind of rationale as to why we would want to invest in this capability.

I think the other bit that's missing here is some kind of rationale as to why we would want to invest in this capability.

Fair, I augmented the OP a bit. Let me know if that's sufficient to understand the motivation.

I think that justifies incoming but not outgoing. It also raises some other questions:

• What about embedding?
• What about channels that are still available, such as storage, BroadcastChannel, shared workers, etc?

I think that justifies incoming but not outgoing

True. Thinking through this, I agree that it doesn't matter for the use case that outgoing opener relationships would be severed.

• What about embedding?

CSP frame ancestors's value of 'none' allows sensitive apps to prevent themselves from being framed by other same-origin apps.

It's true that there may be cases where a frame may want to force itself to be sandboxed from the embedder. (in cases where it needs to be framed by some same-origin apps, but not directly scripted by them)

• What about channels that are still available, such as storage, BroadcastChannel, shared workers, etc?

Those are presumed to be fine as communication between the different apps is permitted. (they are still the same origin)

I think I understand what you mean, but that's a confusing comment given the current set of values. As in, same-origin-allow-popups explicitly does not break the relationship with any popups. It only breaks the incoming cross-origin relationship, if any.

To date we have only used noopener for outgoing relationships, but it might still be reasonable.

Changed to OP to propose the value to be no-opener-allow-popups. Let me know if that's clearer.

After some prototyping, I'm now less certain that this can be achieved without an opt-in from the opener.

Given that window.open() is sync, and that COOP headers are received later on, it's unclear to me we can sever the relationship from the opener to the openee synchronously.

Maybe we can somehow severe it after the headers are received, but I'm not sure how that would look like without creating race conditions.

/cc @camillelamy @ArthurSonzogni

The opener would have a reference to a closed initial about:blank. That's the same as with COOP today, no?

it's unclear to me we can sever the relationship from the opener to the openee synchronously.

A "frame" can't stand without a document. So when creating an <iframe> or a popup, they are both starting from the initial empty document. Creating the pair of frame and its initial document is always synchronous.

This is only after a subsequent navigation (always asynchronous) that we start receiving headers and can decide to instantiate the next document in a different browsing context group.

Maybe we can somehow sever it after the headers are received, but I'm not sure how that would look like without creating race conditions.

From the implementation or specification point of view?
Modifying ShouldSwapBrowsingInstanceForCrossOriginOpenerPolicy in your patch seems right. Hopefully, the COOP implementation can be reused.

So how should this work if a new window is first opened with page A and then later navigated to B and only B uses the new header? The Window(Proxy) A (and B?) uses may have plenty of other references than the opener relationship at that point.

So how should this work if a new window is first opened with page A and then later navigated to B and only B uses the new header? The Window(Proxy) A (and B?) uses may have plenty of other references than the opener relationship at that point.

I think that would be similar to the opener relationship when page A opens a same-origin B, which then navigates to a cross-origin document.

I think that would be similar to the opener relationship when page A opens a same-origin B, which then navigates to a cross-origin document.

That's inaccurate. What I should've said is that it would be similar to the opener relationship when page A with a same-origin COOP opens a same-origin B with same-origin COOP, which then navigates to a same-origin document C with a unsafe-none COOP.

ok, and how does "noopener" in the new value hint about that behavior? Isn't the change you want a tweak to https://html.spec.whatwg.org/#matching-coop so that in some cases that same origin check wouldn't be done (and nothing to do with noopener as such)?

That's indeed what I did in https://github.com/whatwg/html/pull/10394/files

I think what @smaug---- is getting at is that he doesn't find noopener a clear name for severing the incoming relationship as it has thus far only been used to sever the outgoing relationship. However, I'm not sure what he would prefer instead. I personally find noopener[-allow-popups] much clearer than the initially proposed omit, but maybe there is something better?

That, and also this feels like a distinct feature of COOP itself, just like the existing noopener is a feature of its own.

Looking at the definition: "A cross-origin opener policy value allows a document which is navigated to in a top-level browsing context to force the creation of a new top-level browsing context, and a corresponding group"

That seems to be what we want here. Beyond that, we want to prevent the opener from being able to script the document in question. So to me, this very much feels related.

I hesitated a bit on the Report-only mode and how it translates, but after thinking about it, it does seem like something we'd want in order to facilitate deployment here (just like for COOP).

Happy to discuss this further :)

But noopener itself is already a separate functionality in the platform. Is there a reason to not let opened page pages control opener relationship without binding that functionality to COOP.
I can see use cases, at least optimizations, for noopener without COOP. The page could that way try to optimize process usage in browsers, since they are more likely to use separate process when there is no opener relationship. And even more importantly bfcache requires noopener.

What additional functionality does COOP have? I thought this was it.

We discussed about this, and I can live with this. But this needs some documentation outside the normal COOP parts so that people trying to optimize for example bfcache handling can realize there is a way to break opener relationship also from openee side.

(Still feels like mixing two different features conceptually, when noopener from caller side is a separate thingie)

Why does that documentation concern not apply to COOP generally?

It does. But having something called Cross-Origin-Opener-Policy being possibly in a critical path on enabling bfcache even on same origin pages is a bit confusing.

I don't think this value necessarily helps with bfcache though? In particular it still allows the document to open its own popups, which would end up invalidating its cache entry as I understand it.

Right, but you have the existing noopener for those cases.

I guess for bfcache the initial idea of noopener as a value that applies to incoming and outgoing would be quite useful then. If it's indeed the case that bfcache only works if your browsing context group only holds a single top-level browsing context at a time (which sounds about right).

So two things that came up yesterday:

• As mentioned above having noopener as a value would be somewhat useful to be able to guarantee bfcache eligibility. cc @rubberyuzu @fergald
• We need to figure out if this should relate to COEP. This seems somewhat tricky, but I do worry that if we don't explore it now we'll regret it later. cc @camillelamy