Severing a document's openee relationship regardless of origin

[weizman]

What problem are you trying to solve?

JavaScript and the Web are well designed for building composed/composable software, but since doing so safely is a hard task, we witness a positive trend towards attempts to reconfigure how powerful capabilities behave and limit their powers in order to mitigate the extent to which they can be abused.
However, to do so securely, there are still some major blockers to deal with, one of them being the same origin concern where untrusted code within the protected app can escape applied limitations by creating new same origin realms and accessing fresh new instances of the mitigated APIs.
Having no control over such realms translates into not being able to virtualize runtime security in a truly safe manner.
The more complicated variant of same origin realms to defend against is popups.
Therefore, it would be very helpful if the browser would offer some opt-in APIs to limit the access popups of same-origin may have with the protected realm of the app, so that untrusted code within it won’t be able to create a new popup and grab access to its WindowProxy and the capabilities it shares.

An excellent example of that is the implementation of no-opener-allow-popups which was addressed by #10373, only that instead of focusing only on limiting the relationship with the opener, we’d like to introduce the other half of this which is to limit the relationship with the openee.

To be more specific:

• #10373 allows a page that was opened to sever its two-way relationship with its opener (given the openee is protected via no-opener-allow-popups), which means:
  • opener will have access to a closed cross-origin-like WindowProxy (even if it represents a same-origin WindowProxy)
  • the opened page won't have sync (scripting) access to its opener (window.opener=={null/closed WindowProxy})
• However, what's missing is the reverse side of this, where the page that's protected with no-opener-allow-popups isn't the openee, but rather the opener, resulting in a current state where:
  • opener can still have sync access to capabilities provided by a same-origin WindowProxy of a popup it opened
  • openee that was opened by the protected opener can still have access to its protected opener (window.opener!={null/closed WindowProxy})

What solutions exist today?

There are no solutions today to solve this AFAIK.

How would you solve it?

By adding a no-opener value to the Cross-Origin-Opener-Policy header, that would include both the value provided by no-opener-allow-popups and would also mimic its behaviour to apply similar protection to a protected opener, thus protecting both openers and openees that wish to have the protection that the no-opener-allow-popups feature provides.

Anything else?

No Response

[weizman]

This is basically to continue and build off of @yoavweiss's #10373 (cc @camillelamy @arturjanc @ddworken)

[domenic]

What solutions exist today?

There are no solutions today to solve this AFAIK.

Isn't the solution today to use the noopener feature of window.open()?

[weizman]

That's true for when you trust the code that performs such action, but the context here is for untrusted code that runs within the page, for which we'd like to introduce a solution that forces this behaviour on the web page (as an opt-in), so that such untrusted code won't be able to form new same origin realms nor access powerful capabilities/APIs they leak.

[annevk]

This seems reasonable to add to me. It's also why we have both same-origin and same-origin-allow-popups today.