The disown-opener directive is not the right model

[jwatt]

https://w3c.github.io/webappsec-csp/#directive-disown-opener

The current pressing need for disown-opener or something like it is to allow us to keep the at risk opener aspects of the Secure Contexts algorithm (see w3c/webappsec-secure-contexts#42). Disowning the opener doesn't meet the needs of the Secure Contexts spec though, since the worry there is that the opener's connection to the openee (rather that visa versa) allows the opener to postMessage to the openee to potentially gain access to secure context-only APIs it otherwise shouldn't have access to. So rather than breaking the connection from the openee to the opener as the disown-opener directive would do, what we really want is to break the connection from the opener to the openee, or at least to prevent postMessage messages making it through to the openee.

[jwatt]

Maybe the directive should be called something like new-window-connection, take a serialized-source-list as its value, and if the source does not match then the connection in both directions should be "broken"...somehow.

[laukstein]

Why is not named noopener since expected to be equal to rel=noopener as far I know?

[andypaicu]

I would like to re-open this discussion around this perhaps we could reach a good solution that is good for Secure Contexts (w3c/webappsec-secure-contexts#42).

It sounds to me that the disown-opener directive does not really do what is needed and I think this is different enough from that that is should have a separate directive. Maybe something like disown-parent.

What I'm not sure about is how important is the serialized-source-list idea. Would a simple cross-origin check be good enough? If the parent is cross-origin then we disown it?

[AliceWonderMiscreations]

Would it be better if this was a separate header from CSP? Because it seems to me that the restricted behavior of how the opener works may depend upon the domain that is linked to, which I think is beyond what CSP is for.

However it is highly likely I do not fully understand what this directive is suppose to do.

[baptx]

@AliceWonderMiscreations good question, it reminds me that the HTTP header equivalent to the HTML attribute rel="noreferrer" was first a CSP directive and it was then deprecated with the separate header Referrer-Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer
Like @laukstein, I wonder why the header is not called noopener or no-opener which is simpler and more consistent with the HTML attribute (like the Referrer-Policy header with the no-referrer value).

[laukstein]

Why so many new headers? Why not merge it in single header like does CSP and Feature-Policy?

[annevk]

This is now COOP (see whatwg/html#3740).