About rel=noopener • Hacker News Board

Re: About rel=noopener

#61

Post by lazyjones » Sat, Apr 23, 2016, 7:14 AM UTC

panic wrote: post #47

epidemian wrote: post #43

Earlier quoted context omitted.

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 th…

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.

> you'd be breaking a million sites with your change.

Websites relying on such obscure misbehavior are already broken in my book. Fixing them would solve the problem better and cause fewer new problems for everyone else.

Re: About rel=noopener

#62

Post by panic » Sat, Apr 23, 2016, 7:17 AM UTC

lazyjones wrote: post #61

panic wrote: post #47

Earlier quoted context omitted.

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.

> you'd be breaking a million sites with your change. Websites relying on such obscure misbehavior are already broken in my book. Fixing them would solve the problem better and cause fewer new problems for everyone else.

They aren't already broken for the people who rely on them.

Re: About rel=noopener

#63

Post by PinguTS » Sat, Apr 23, 2016, 7:35 AM UTC

epidemian wrote: post #43

reitanqild wrote: post #40

Earlier quoted context omitted.

> 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?

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 th…

For example Typo3 is using that, when you need to select something to be inserted/referenced into the current record. So any, Typo3 based website would break.

Re: About rel=noopener

#64

Post by circlingthesun » Sat, Apr 23, 2016, 7:42 AM UTC

epidemian wrote: post #29

stormbrew wrote: post #26

> 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?

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 [all…

This common with OAuth flows. User clicks "login with x", a popup opens that redirects to an authorization page on x. The user then logs in on x, and gets redirected back to origin that takes the token in the hash fragment, and passes it back to the page the user is trying to login to, via window.opener.

Re: About rel=noopener

#65

Post by azazqadir » Sat, Apr 23, 2016, 7:44 AM UTC

Dru89 wrote: post #12

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.

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

Is there any internet user who doesn't know how to open in new tab? Just curious to what type of users they would be.

Re: About rel=noopener

#66

Post by azazqadir » Sat, Apr 23, 2016, 7:46 AM UTC

xuki wrote: post #37

hueving wrote: post #30

Earlier quoted context omitted.

That's more of a happy accident. Their primary reason is to track things.

You can track click without a redirect.

Like using utm?

Re: About rel=noopener

#67

Post by lazyjones » Sat, Apr 23, 2016, 8:04 AM UTC

panic wrote: post #62

lazyjones wrote: post #61

Earlier quoted context omitted.

> you'd be breaking a million sites with your change. Websites relying on such obscure misbehavior are already broken in my book. Fixing them would solve the problem better and cause fewer new problems for everyone else.

They aren't already broken for the people who rely on them.

It's a security risk, some sites relying on this will be affected by malicious content on sites they link to, so at the very least they'll now have to add one of the 2 limiting rel attributes on links that do not require the misbehavior to function.

Thanks to the bright and sensible handful of people who add extra cruft to HTML after a brief exchange on a mailing list 3 years after a problem was reported, the other 99.9% of the websites will have to be modified too.

Re: About rel=noopener

#68

Post by etatoby » Sat, Apr 23, 2016, 8:23 AM UTC

adrianN wrote: post #28

NoScript saves the day again.

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.

Re: About rel=noopener

#69

Post by etatoby » Sat, Apr 23, 2016, 8:45 AM UTC

stormbrew wrote: post #26

> 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?

Here's my guess: some of Google's / Alphabet's nefarious practices include collecting information on users' previous pages. Fixing this bug the correct way (disabling window.opener by default when cross-origin) would put a dent on their cut, so they're using their leading browser to try and influence how the rest of the world tackles this issue: putting the burden on developers means 99.99% of websites will remain open to this bug and to their data collection.

Time to find Firefox's equivalent issue page and convince them not to follow the leader.

Re: About rel=noopener

#70

Post by bigblind » Sat, Apr 23, 2016, 8:51 AM UTC

circlingthesun wrote: post #64

epidemian wrote: post #29

Earlier quoted context omitted.

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 [all…

This common with OAuth flows. User clicks "login with x", a popup opens that redirects to an authorization page on x. The user then logs in on x, and gets redirected back to origin that takes the token in the hash fragment, and passes it back to the page the user is trying to login to, via window.opener.

Most of these use postMessage.