Severing a document's opener relationship regardless of origin

[yoavweiss]

What problem are you trying to solve?

Some origins can contain different applications with different levels of security requirements. In those cases, it can be beneficial to prevent scripts running in one application from being able to open and script pages of another same-origin application.

In such cases, it can be beneficial for a document to ensure it has a null opener, even if the document that opened it is a same-origin one.

It'd be great if COOP included a value that enabled that.

What solutions exist today?

There are no solutions today to solve this AFAIK.

How would you solve it?

By adding a no-opener-allow-popups value to the Cross-Origin-Opener-Policy header, that results in a null opener when calling creating a new top level travesable.

Anything else?

No response

[yoavweiss]

/cc @camillelamy

[annevk]

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?

[yoavweiss]

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.

[annevk]

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.

[yoavweiss]

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.

[annevk]

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?

[yoavweiss]

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)

[yoavweiss]

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.

[yoavweiss]

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

[annevk]

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

[ArthurSonzogni]

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