If someone gets to your secure site via a <a target="_blank">, you're *not* allowed to use secure-only features.https://github.com/w3c/webappsec-secure-contexts/issues/42 …
-
-
Replying to @jaffathecake
…that's only if the site containing the <a target="_blank"> is itself not-secure btw.
3 replies 2 retweets 3 likes -
Replying to @jaffathecake
is it a chrome limitation of enabling security by process not by page?
1 reply 0 retweets 0 likes -
Replying to @FremyCompany
no. It's because the non-secure page has a communications link to the secure one. & can navigate it.
1 reply 0 retweets 0 likes -
Replying to @jaffathecake @FremyCompany
What
@jaffathecake said. https://mathiasbynens.github.io/rel-noopener/ gives an example of the impact that can have.4 replies 0 retweets 2 likes -
Replying to @mathias @jaffathecake
I think that's a case for not allowing opener access across security boundaries at all in this case. Different thing.
1 reply 0 retweets 0 likes
Replying to @FremyCompany
You’re absolutely right! @jaffathecake
10:53 AM - 25 Jul 2016
0 replies
0 retweets
0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.