
About rel=noopener - dmnd
https://mathiasbynens.github.io/rel-noopener/?target=_blank
======
stormbrew
> Note that this also works when index.html and malicious.html are on
> different origins — window.opener.location is accessible across origins!

... Why. Why would anyone (not maliciously) consider this desirable behaviour?

~~~
epidemian
Agreed. But what's more intriguing to me is that the proposed "solution" is to
add yet another hack on top of that (rel=noopener), instead of doing something
to fix the broken behavior of target=_blank.

I doubt that many sites rely on this broken behavior. And even if they do,
browsers could still block it and show some warning to the user "Hey, this tab
that just opened wants to change the URL of this other tab [allow, always,
nope, never]", just like they do for popup windows or sites with broken SSL
certs.

Does someone with more experience in these kind of issues know why it was
decided to put the responsibility of fixing this on individual websites
(rel=noopener) instead of browsers (blocking the URL changing or showing a
warning)?

~~~
reitanqild
> I doubt that many sites rely on this broken behavior.

Any web based system where a pop up dialog is opened to allow the user to
select something that is then inserted into the original page?

~~~
epidemian
Good call! I guess i haven't seen any of those. But i've seen some internal
web based systems that relied too heavily on popup windows and started
breaking when tabbed browsing became a thing and brosers started blocking
popup windows by default, so i don't doubt that there are probably systems out
there relying on this weird behavior of target=_blank.

For those systems, though, i'd imagine most of them would have these popup
windows on the same origin, right? So having browsers prevent child windows
changing their parent's location _if they are cross-origin_ seems like a
sensible idea, or am i missing something else?

~~~
panic
There are more than 1 billion websites. If just 0.1% of sites use
target=_blank like that, you'd be breaking a million sites with your change.
You can't use arguments like "I haven't seen any of those" or it "seems like a
sensible idea" when making decisions like this.

~~~
epidemian
The "I haven't seen any of those" was just as a comment on why i couldn't
think of possible uses for this target=_blank behavior, not a justification
for the proposed change (what a lame justification that would be! :)

That being said, i don't see how the proposal of browsers blocking popup
windows from redirecting the parent window (if it's cross-origin) by default
is any different from, for instance, them blocking popup windows from opening
unless it was a user action that triggered them, which all browsers started
doing by default quite some time ago. Could you elaborate on why this wouldn't
be a sensible solution?

~~~
panic
It does seem like a sensible solution, but the web isn't exactly a sensible
place. People use terribly-written web sites for all sorts of things that are
important to them in their life. Changes that potentially break these sites
shouldn't be taken lightly.

------
teej
This is the new pop-under. Sites trying to serve as many ads as possible will
open links with target=_blank and redirect the old window to an ad.

~~~
happyslobro
So that's what's happening! With uBlock, all I see is a flicker on the
browser's tab bar, and my history is gone. It's still annoyingly retarded.

~~~
gorhill
I did try to provide a fix for the history-lost case for when a popunder is
blocked, but in the end I had to give up because there was no way to make it
work reliably (using current extensions API).

[1]
[https://github.com/gorhill/uBlock/issues/1028](https://github.com/gorhill/uBlock/issues/1028)

~~~
happyslobro
Ha, no worries, I wouldn't have expected an ad blocker to know that for me,
the dead tab and this new tab are semantically one. I'm just glad that the bad
tab is dead. It's the ad that I was calling retarded :p

Awesome work btw, it runs like greased lightning in FF nightly.

------
jklinger410
Ths is a problem for Browsers, not developers. target=_blank is too embedded
into the web.

~~~
jay_kyburz
developers can fix the problem for their users.

~~~
jklinger410
It's more expensive for a web dev to fix this than a browser to prevent it.

------
Dru89
What is the correct way to force a link to open in a new tab, then?

Unfortunately "let the user decide" is not the best answer if you want to link
to something like "terms and conditions" in the middle of a sign up flow or
something. If the user doesn't know how to open it in a new tab on their own,
this can be extremely frustrating I'd imagine.

~~~
wtbob
> What is the correct way to force a link to open in a new tab, then?

What is the correct way to stalk, hunt, kill, stuff and mount the user?

Answer: there is no correct way to do something which is fundamentally
incorrect.

> Unfortunately "let the user decide" is not the best answer if you want to
> link to something like "terms and conditions" in the middle of a sign up
> flow or something. If the user doesn't know how to open it in a new tab on
> their own, this can be extremely frustrating I'd imagine.

Abusing _my_ browser is extremely frustrating for me. If I want to open a link
(a link, see, not some horrid piece of JavaScript) in a different tab, I
middle-click and get on with life. You don't need to do that for me, any more
than you need to offer me a typing widget when I have a perfectly functional
keyboard, or fake a link when I have a browser perfectly capable of understand
the <a> tag, or check my (correct) email address with an incorrect regular
expression.

Please don't break the Internet.

~~~
douche
On the other hand, I almost never want to have a link open in the same tab.
There's nothing more frustrating than being halfway down a page, forget to
hold down ctrl when I click on a link, and have all of my state on the old
page blown away and replaced with the new one.

Probably this is a result of the internet _already_ being broken, since the
worst of it is in infite-scrolling type things where my confidence that I can
get back to where I was originally after going back is very, very low.

~~~
MichaelApproved
If you have a middle mouse button, you can middle click a link to open it in a
new tab. Of course, that's if you didn't reprogram the middle button to do
something else.

~~~
jevinskie
Reprogramming the meat behind the keyboard is often harder than reprogramming
the machine.

------
donatj
Well I just had an "Oh sh*t" moment thinking about all the websites I built
over the years at my old company that had target=_blank to commentors sites...
Aw crap.

Not my problem anymore, but I never even considered this.

~~~
knowtheory
Maybe you could send them a note? Do you know anybody who's still working on
the project?

~~~
donatj
It's a complicated situation. They owe me a bit of money and don't reply to
any of my emails.

~~~
colejohnson66
Can't you sue them then? Or at the least threaten to sue?

~~~
donatj
If you see my story which I commented on a different post in the hierarchy,
it's VERY complicated.

------
ddoolin
Is there a practical reason that a reference to the opener window is given to
the opened window? That seems like something we could do without.

~~~
krastanov
Example: Google Slides where one tab has the presentation and another tab has
the speaker notes. You want those to be in sync.

~~~
nsgi
There are plenty of other ways to do this e.g. web sockets or localStorage.

~~~
acdha
Now, yes, but a lot of precedent was set before then. Even now both of the
technologies you mentioned would add significant complexity – needing to start
running an otherwise unnecessary WebSocket server, having to debug and
workaround client bugs or network issues like large organizations blocking
WebSockets.

------
pmalynin
This is a pretty old bug, I think I reported it a few years ago to Google.

EDIT: 2013 to be exact.

~~~
jaredsohn
FYI, the article links to a Chromium issue from 2013:

[https://bugs.chromium.org/p/chromium/issues/detail?id=168988](https://bugs.chromium.org/p/chromium/issues/detail?id=168988)

which links to another issue from 2012.

Edit: My purpose was to confirm the bug has been "known" for awhile, not to
take away credit for you reporting the bug years ago. Congrats for
independently discovering it before many people (such as myself) became aware
of it.

~~~
pmalynin
Well there you go, although I submitted it trough a different channel.

For sure, I think its a very important bug that hasn't had much attention for
years now, especially since so many websites use _blank, GMail being one of
them.

~~~
ptoomey3
I get that linking from a "trusted site" to a "not trusted site" is probably
of greater concern. But, this `noopener` does nothing to address a similar
attack demonstrated here:
[http://lcamtuf.coredump.cx/switch/](http://lcamtuf.coredump.cx/switch/).

------
detaro
If you open a page of your own site that then redirects to the target (like
some pages do, presumably to hide the exact source URL in the referer-header
before there was a header for it), is the opener-reference broken?

------
doughj3
I'm using Chromium and even the link with `rel=noopener` seems to be able to
"hax" the first page. Am I reading it wrong or is `rel=noopener` supposed to
protect against this?

~~~
illuna
It's a bit confusing if you didn't pay close attention to the article, because
neither link actually show the `rel=noopener` fix.

Instead, the two links present two different angles to the same problem. The
first link demonstrates the attack using a page within the same domain
(reasonable), and the second demonstrates that it will continue to work even
when the link points to a page ordinarily restricted by cross-origin policies
(potentially surprising).

If you manually add `rel=noopener` to either link, the attack won't work. Try
it with DevTools.

------
vortico
Note that all the opened page has control over is closing and changing the
address of the tab. You can't insert HTML into the page, for example. Phishing
seems to be the only problem this creates, but no more.

------
jaredsohn
I built a quick userscript that treats rel="noopener" as default for links
with target:"_blank".

It could be worth checking out if you want to avoid experiencing this security
issue yourself (but I offer no warranties) or if you want to see if it would
break any site you visit if browsers would enable the behavior by default.

[https://github.com/jaredsohn/noopener_by_default](https://github.com/jaredsohn/noopener_by_default)

------
homakov
They ever heard of "security by default"? I guess no.

~~~
bzbarsky
In the early to mid '90s, threat models on the web were quite a bit different
from now.

~~~
homakov
I was implying "make it a default for everyone, now"

~~~
bzbarsky
Right, but now you have 20 years worth of content which depends on the current
behavior....

~~~
homakov
On this particular behavior unlikely

~~~
bzbarsky
What makes you think this is unlikely? On the contrary, I think it's _very_
likely there are things depending on it. I don't expect there to be a huge
number of them, but I also expect them to disproportionately be in things like
intranet deployments where it's hard to even get measurements. :(

~~~
homakov
A link with _blank + expected to change/interact with opener? Maybe there's a
few, but most cross domain transports would use window.open() manually.

~~~
bzbarsky
Well, window.open() obviously has the same problem, with the same solution
being proposed: the caller of window.open opts in to not allow the thing being
opened to interact with it.

We could have different default behaviors for the two cases, of course: opt-in
for links and opt-out for window.open.

But I still suspect that even just the link case is not as uncommon as one
might wish. Happy to see data proving me wrong, though!

------
adrianN
NoScript saves the day again.

~~~
etatoby
Yeah, except breaking 99% of the modern Web.

NoScript has its place, for example in the Tor browser or in other high-
security applications, but it's too much of a burden for everyday use.

~~~
pdkl95
If your website _breaks_ without Javascript, then it's the website's fault for
not properly implementing progressive enhancement. Javascript is useful to
_enhance_ the page with better features, but the page itself should work
without it.

If you tools/framework make this hard or generate output that incompatible
with progressive enhancement, then I suggest you find (or write) better tools.

~~~
Strom
I do wonder for how many sites does this actually make sense to do. Take the
number of users who use NoScript and are not willing to turn it off when the
site doesn't work without JS, and then take the subset from those who would
actually be willing to pay for using the website. [1] Do these niche users
really generate enough revenue to pay for the toolchain & work culture changes
necessary to have this progressive enhancement? What's more, this group of
users doesn't even receive the charity boost that some other niche groups like
the visually impaired might receive, that would lead to changes even without
direct financial sense.

[1] Being NoScript users, they most likely also run some sort of ad blocker,
so ad revenue from them is likely zero.

~~~
pdkl95
> makes sense to do

Do you use the pointer that fopen(3) returns without checking for NULL?
Progressive enhancement is mainly error checking and handing failures
gracefully.

> not willing to turn it off when the site doesn't work without JS

Why are you willing to make your business look shoddy and unprofessional?
Running without javascript has always been an option, and always will be.
Anyone that doesn't run the javascript obviously isn't expecting fancy
features, but you should still show any text/images (or a basic form if that
is relevant), probably along a suggestion that turning on javascript will
probably improve their experience.

> changes necessary to have this progressive enhancement

That's the point - this shouldn't cost a lot, unless your tools are unusually
braindead. Rails made progressive enhancement almost entirely transparent a
long time ago. I believe there are several prerender-the-first-load plugins
for several popular frameworks. If your tools aren't doing this for you
(either automagically or otherwise), then those tools are missing important
features.

> work culture changes

It is probably a good idea to pay any technical debt sooner, instead of tying
even more projects to bad tools.

> users who use NoScript

NoScript users are _NOT_ [1] the only group that will see your pages without
Javascript. You don't control the client, which will always be unreliable.

Also, progressive enhancement isn't a boolean value; you should be checking
for the availability of any feature you use. This may result in only partial
support, which is probably better than _no_ support (or a javascript error) if
someone loads your page in an old browser or something unusual. The web is
inherently a fluid environment, which makes defensive programming even more
important.

> direct financial sense

What is the direct financial impact of showing people a broken website? Do you
even analyze the server logs to find out how many people are impacted?

[1]
[http://kryogenix.org/code/browser/everyonehasjs.html](http://kryogenix.org/code/browser/everyonehasjs.html)

------
Grom_PE
Some time ago I was surprised that my Google Search page was replaced by
something else after I returned from some spammy page (opened in another tab).

As the browser I use, Opera 12, also treats all links manually opened in the
new tab as if they had target="_blank", giving them opener access, I decided
to remove the window.opener altogether by replacing the "opener" string with
"opera" in the opera.dll. This way it gets overwritten by the normal
window.opera variable and is essentially hidden. So far I haven't encountered
a site legitimately relying on this behavior.

------
zspitzer
wouldn't a simple solution be <base rel="noopener">

------
carey
In the right circumstances, which as far as I can tell are when crossing
between security zones, Internet Explorer and Edge already seem to block this.
I've never been able to pin down exactly what's happening, or to get Google
login to work on our intranet sites with IE as a result.

------
nsgi
There should be an option in content security policy to prevent this on all
links.

------
mindcrime
_sigh_ This is a perfect example of a title that should _not_ have been
changed. The original was objectively better than the current one. If you
don't already know what rel=noopener is, you'd have no reason at all to click
through on this. But the earlier title actually explained something _about_
the content on the other end of the link.

~~~
dmnd
HN submissions are kind of like startups. Often you have to break the rules to
get off the ground. But once you have some lift, it's time to become boring
and straighten out.

~~~
lumpypua
I have no idea what this submission is about. Why would I want rel=noopener?

~~~
notatoad
The original title (and the point of the article) was about the security
problems target=_blank has.

You want rel=noopener because the page it navigates to can't affect the
content of the opening page.

------
_RPM
Does this "work" for cross origin requests? If I plant a `target=_blank` in my
website, user clicks it, goes to my second website, do I have control over the
website the link came from? If not, I don't see the security issue. Of course
you can XSS yourself, what have you.

~~~
kalmi10
To some extent.. Yes.

The attacker can replace the current page with his own phising page.

Of course, the hostname part of the url would change, but the user is unlikely
to notice that.

~~~
colejohnson66
Case in point: People still fall for things like
`facebook.com.totallynotaphishingsite.com'

~~~
mort96
It's a huge difference between clicking on a random
facebook.com.totallynotphishing.com link, and being on the legitimate
facebook.com and having that tab automatically go to a phishing site while
you're not looking.

