
About rel=noopener (2016) - edance
https://mathiasbynens.github.io/rel-noopener/
======
billpg
Shouldn't this behavior be explicitly enabled, defaulting to disallowing it?

Or do I need to tag all my links with a long series of "Don't allow this crazy
thing", "Or that other thing", etc.

~~~
kijin
Lots of existing apps, including some that handle payment information, rely on
window.opener to provide a seamless experience when using pop-ups or iframes
from a different domain.

In an ideal world, these apps would have been rewritten a long time ago using
more modern techniques. In reality, browsers bend over backwards to maintain
backward compatibility with existing apps.

~~~
metafunctor
I remember this very thing being discussed years ago.

Since this is still a problem, I'd say the web needs a way to gracefully
migrate away from bad decisions like window.opener being available across
origins.

Should we not decide that cross-origin window.opener is now deprecated, show
big fat warnings on the developer console when it's used, and remove it in a
year or two? I'd like an option to completely turn it off on my browser. Like
third-party cookies, cross-origin access to just about anything is a bad idea.

~~~
beaconstudios
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to
break backwards compatibility across the board and have sites opt in to use v2
using some kind of flag. The benefits would be massive but it would also
require browsers to essentially have 2 different engines to support both
legacy and v2 websites.

~~~
Forge36
Internet Explorer tried to maintain multiple rendering engines. Every version
from IE5 to IE11 (if you open the debug console you can switch rendering
modes) And now they have Edge. It never took off.

I suspect the cost of breaking web compatibility intentionally to accomplish
this goal would kill a browser, as authentication, payment, and many other
things would suddenly break.

~~~
beaconstudios
this is why I say it would have to be opt-in through something like a header
or tag on the page in question (although I don't think doctype would work well
for this). Existing sites would use the current engine and sites that
explicitly stated they were for the new engine would be handled differently.

~~~
manigandham
That's exactly what IE did with the `X-UA-Compatible` meta tag. It's just more
work for both browsers and websites to manage, which is why it's not used
anymore.

[https://msdn.microsoft.com/en-
us/library/jj676915(v=vs.85).a...](https://msdn.microsoft.com/en-
us/library/jj676915\(v=vs.85\).aspx)

------
MrRadar
There's a Firefox extension to add the rel=noopener attribute to all links
(except ones to the same domain): [https://addons.mozilla.org/en-
US/firefox/addon/dont-touch-my...](https://addons.mozilla.org/en-
US/firefox/addon/dont-touch-my-tabs/?src=userprofile)

~~~
jkeat
Here's one for Chrome: [https://chrome.google.com/webstore/detail/no-opener-
no-phish...](https://chrome.google.com/webstore/detail/no-opener-no-
phishers/hieejlcohhkjbpiihgphcnaaiehphike)

~~~
JamieF1
I made that! Thanks for sharing, didn't expect someone to know about it.

------
epmatsw
There’s also a disown-opener CSP directive that’s hopefully going to be
implemented at some point. Should help take care of this.

~~~
madeofpalk
On the same note, in the JSX plugin for ESLint, there's a rule to warn against
target="_blank" without rel="noopener". Very handy.

------
davidmurdoch
My totally unmeasured hunch is that there is a downside to using noopener: it
could make the new page that is being opened take slightly longer, since it
now needs to spool up another process/thread/sandbox/whatever instead of piggy
backing off the existing page's.

More about the performance "benefit" here:
[https://jakearchibald.com/2016/performance-benefits-of-
rel-n...](https://jakearchibald.com/2016/performance-benefits-of-rel-
noopener/)

~~~
anewhnaccount2
That page says the opposite of what you just said.

~~~
davidmurdoch
For an origin page utilizing 100% of it's available processor resources, yes.

But in the real world most websites don't do this. What likely matters to the
user is that the page they're navigating _to_ opens faster; the user likely
doesn't care about the performance of the hidden tab they just came from.

Of course, `noopener` has security and privacy benefits which may outweigh the
performance costs (if there are any).

------
eddieD401
Excellent, concise and with solid examples too! I can't see any reason to not
expect this as the default behavior, especially in today's hostile climate. It
almost seems as if the standards writers have a stake in making sure there is
always a place in the picnic basket for an unseen finger...

------
Retr0spectrum
Why has this post been flagged?

~~~
SquareWheel
Likely because it has been posted many times already. I've read it at least
three times now.

~~~
linkmotif
But have you truly internalized it?

~~~
SquareWheel
I still use rel="noopener noreferrer" on _blank links, but it's less of an
issue than it was when first reported.

~~~
lioeters
Could you elaborate on how it's less on an issue than before? Have browsers
implemented some security strategies since the article was published?

I've seen this article (OP) a few times already, and it keeps reminding me to
add rel="noopener noreferrer" on whatever site/system I'm working with at the
time. In fact I just did that yesterday when I saw this article, to set up a
way to automatically add it for external links, in my current dev workflow.

~~~
SquareWheel
I'm going off of the tickets linked in the footer of the article, which seem
to show they're being resolved.

~~~
lioeters
Ah I see that now, it escaped my notice earlier. Thank you, that's good to
know!

------
jarofgreen
I think this is an older article?* Any updates on support?

* I also don't understand how this is being served. If you go to [https://github.com/mathiasbynens](https://github.com/mathiasbynens) there should be a repository called mathiasbynens.github.io right? But I can't find it.

~~~
sim0n
> there should be a repository called mathiasbynens.github.io right

Not exactly - the subdomain is the account and the path name is the repository
(and the repository's `gh-pages` branch is what's returned).

([https://github.com/mathiasbynens/rel-
noopener](https://github.com/mathiasbynens/rel-noopener))

~~~
jarofgreen
Didn't know you could do that, thanks! Also, this confirms last edit Nov 2016.

