Earlier quoted context omitted.
It would be helpful if you stated what the original title actually was, especially now that you have the top-level post!
It was something like "TIL: target=_blank is harmful"
s/harmful/insecure/
IIRC.
About rel=noopener
41–50 of 115 posts
Re: About rel=noopener
#42This 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.
Yeah. This is amazingly irritating.
Re: About rel=noopener
#43Earlier 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…
> 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 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?
Re: About rel=noopener
#44Earlier quoted context omitted.
This is one of the reasons why FB et al go to a special link before opening the actual target site.
That's more of a happy accident. Their primary reason is to track things.
I thought the primary reason was privacy: https://m.facebook.com/notes/facebook-engineering/protecting...
Re: About rel=noopener
#45Earlier 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…
> 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?
Probably there are, but they're hardly likely to rely on it working cross-origin, and if they are they almost deserve to have it broken...
Re: About rel=noopener
#46Re: About rel=noopener
#47Earlier 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…
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.
Re: About rel=noopener
#48They ever heard of "security by default"? I guess no.
Security is hard, especially if your opponent is more clever than you. For example, the internet years later.
Re: About rel=noopener
#49Earlier 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?
Probably there are, but they're hardly likely to rely on it working cross-origin, and if they are they almost deserve to have it broken...
Not sure but I would think anything that use a pop up to login using social media account would like to get an event back when successfully logged in?
Re: About rel=noopener
#50Is 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.
Example: Google Slides where one tab has the presentation and another tab has the speaker notes. You want those to be in sync.
But presumably this example is not cross-domain. This behaviour should not be allowed by default for cross-domain links!