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.

Sign up for GitHub

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

Jump to bottom

Way to disown window.opener and become a secure context #517

Closed
jakearchibald opened this issue Jul 25, 2016 · 5 comments
Closed

Way to disown window.opener and become a secure context #517

jakearchibald opened this issue Jul 25, 2016 · 5 comments

Comments

@jakearchibald
Copy link

jakearchibald commented Jul 25, 2016 •
edited
Loading

Similar to #139 but for this window.

If http://example.com contains:

<h1>Check out thes cooool web appz:</h1>
<ul>
  <li><a href="https://jakearchibald.github.io/svgomg/" target="_blank">SVGOMG</a></li>
  …
</ul>

…and the user clicks on that link, I can't use geolocation because I'm not a secure context. It'd be nice to prevent that.

Unfortunately we'll need a different mechanism for service worker, which needs to be secure before handling the navigation fetch.
@jakearchibald jakearchibald mentioned this issue Jul 25, 2016
Closed
mikewest added a commit to w3c/webappsec-csp that referenced this issue Jul 25, 2016
@mikewest
Stubbing out 'disown-opener'.
68330f3 
w3c/webappsec#517 asked for this, and it's a totally reasonable thing to do.
But, w3c/webappsec#139 asked for the inverse ('disown-openee' or something),
and it's not clear to me whether there's a good syntax that might encompass
both.

Leaving both tickets open until we come up with something we're happy with.
Until then, puttign this stub in place.
@delapuente
Copy link

I think you mean a link with target="_blank". Does not it?

@mikewest mikewest mentioned this issue Jul 29, 2016
Closed
@jakearchibald
Copy link
Author

Oops, yep. Updated.

@yoavweiss
Copy link
Contributor

Unfortunately we'll need a different mechanism for service worker, which needs to be secure before handling the navigation fetch.

Can we make that value "sticky" so that sites that declare it once (perhaps with a certain max-age) will have this property when opened later? That way sites can add this opener opt-out on the initial navigation, and SW would be able to use the same opt-out.

@yoavweiss
Copy link
Contributor

At the same time, auto-disowning opener is probably a good idea on its own.

@annevk
Copy link
Member

annevk commented Dec 10, 2018

Superseded by whatwg/html#4078 and whatwg/html#3740.

@annevk annevk closed this as completed Dec 10, 2018
ryandel8834 added a commit to ryandel8834/WebAppSec-CSP that referenced this issue Aug 13, 2022
@ryandel8834
Stubbing out 'disown-opener'.
10cd531 
w3c/webappsec#517 asked for this, and it's a totally reasonable thing to do.
But, w3c/webappsec#139 asked for the inverse ('disown-openee' or something),
and it's not clear to me whether there's a good syntax that might encompass
both.

Leaving both tickets open until we come up with something we're happy with.
Until then, puttign this stub in place.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jakearchibald @delapuente @yoavweiss @annevk