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

Open
jwatt opened this Issue Mar 13, 2017 · 7 comments

Comments

Projects
None yet
7 participants
@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.

Show comment
Hide comment
@jwatt

jwatt 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.

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.

@mikewest mikewest modified the milestone: CSP3 CR May 9, 2017

@laukstein

This comment has been minimized.

Show comment
Hide comment
@laukstein

laukstein Sep 7, 2017

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

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

@andypaicu

This comment has been minimized.

Show comment
Hide comment
@andypaicu

andypaicu Oct 9, 2017

Collaborator

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?

Collaborator

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

Push rules live
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)

@andypaicu andypaicu modified the milestones: CSP3 CR, Future Jan 9, 2018

@AliceWonderMiscreations

This comment has been minimized.

Show comment
Hide comment
@AliceWonderMiscreations

AliceWonderMiscreations 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.

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.

Show comment
Hide comment
@baptx

baptx 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).

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).

@Malvoz

This comment has been minimized.

Show comment
Hide comment
@Malvoz

Malvoz Jul 30, 2018

@andypaicu, @mikewest Does Cross-Origin-Window-Policy replace/make disown-opener or similar model obsolete?

Malvoz commented Jul 30, 2018

@andypaicu, @mikewest Does Cross-Origin-Window-Policy replace/make disown-opener or similar model obsolete?

@laukstein

This comment has been minimized.

Show comment
Hide comment
@laukstein

laukstein Jul 30, 2018

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment