Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The `disown-opener` directive is not the right model #194

Closed
jwatt opened this issue Mar 13, 2017 · 7 comments
Closed

The `disown-opener` directive is not the right model #194

jwatt opened this issue Mar 13, 2017 · 7 comments
Assignees
Milestone

Comments

@jwatt
Copy link

@jwatt jwatt commented Mar 13, 2017

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

This comment has been minimized.

Copy link
Author

@jwatt jwatt commented Mar 13, 2017

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

This comment has been minimized.

Copy link

@laukstein laukstein commented Sep 7, 2017

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

@andypaicu

This comment has been minimized.

Copy link
Collaborator

@andypaicu andypaicu commented Oct 9, 2017

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?

@andypaicu andypaicu self-assigned this Oct 9, 2017
jloh added a commit to jloh/geojs-app that referenced this issue Jan 7, 2018
The change to connect-src didn't seem to actually do anyhing weirdly, leaving it as is
disown-opener  doesn't seem to be implemented yet (w3c/webappsec-csp#194)
@AliceWonderMiscreations

This comment has been minimized.

Copy link

@AliceWonderMiscreations AliceWonderMiscreations commented Mar 28, 2018

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

This comment has been minimized.

Copy link

@baptx baptx commented Jun 2, 2018

@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

This comment has been minimized.

Copy link

@laukstein laukstein commented Jul 30, 2018

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

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Aug 8, 2019

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

@annevk annevk closed this Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.