Hacker News Reader

Comment by epidemian | Hacker News Reader

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

View on HN

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.

probably window.opener.postMessage. Though that doesn't excuse window.opener.location not being blocked in the name of the Same-Origin Policy...

"location" is not blocked cross-origin, because that allows you to navigate windows you opened, or subframes of yourself, even if they happen to not be same-origin with you at the moment. And it's been this way for over 20 years, and sites commonly depend on it. :(

So what you're suggesting is either some sort of asymmetric "same-origin" checks or .... something.

I don't really see the problem with making this asymmetrical. The security implications of a frame navigating its parent and a parent navigating its child frame seem very clearly different to my mind.

If you're suggesting it would be technically difficult, I'm extremely skeptical of that. The origin's relationship to the target frame should not be impossible to discern, and I'd be a little shocked if it isn't taken into account elsewhere.

The problem with making it asymmetrical is that in the case of two toplevel tabs (as opposed to frame and child) determining who's the "parent" and who's the "child" is a lot more complicated.

> If you're suggesting it would be technically difficult, I'm extremely skeptical of that.

I think it's technically difficult to establish parent/child relationships between toplevel windows, given opener disowning and so forth.

That's not even getting into the possible compat issues, of course, from the behavior change itself.

If that relationship weren't clear you wouldn't have a window.opener attribute to begin with.

That said, I'm also skeptical of legitimate uses for controlling the location of another top level window as well, so I'm fine with killing that option too.

Of course, I don't expect them to actually fix this, but I'm still waiting for a convincing argument that it should have been that way in the first place.

My point was that window.opener can be nulled out.

> I'm also skeptical of legitimate uses for controlling the location of another top level window as well

Happens all the time: open a popup, then navigate it to places. Not on web pages much nowadays, though it was more common in the past, but in various intranet apps? All the time.

I'm sure it can. That does not mean the browser needs to forget it. The parent/child relationship of browser windows is not some massive technological feat.

That something is used does not mean it is legitimate. I am not disputing that it is used. I am not saying I think they'll fix it. I am questioning the validity of the decision to allow it in the first place. I have no doubt that other means would be found to achieve the same end goals if it were not available.

> That something is used does not mean it is legitimate.

While I agree, in practice what this means is that either all browsers need to coordinate rollout precisely (and even then the result will be that many users just stay on insecure versions of browsers instead of updating) or you will have pages (or employers) telling users to switch to whatever browser lags in rolling this out.

We've seen this play out before. The result is that you end up with users picking whichever browser defects (which reduces the incentive for other browsers to do this) or being stuck on the equivalent of IE6.

The benefit of changes that do NOT break compat is that browsers can just roll them out without needing to worry about the above side-effects.

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

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.

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?

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.

Should the parent window be able to navigate the popup window, even if it's cross origin?

If not, now you're suggesting some sort of asymmetric security checks that depend on something that's not just the origins. Security checks that, chances are, will be easy to evade by malicious actors. At least I haven't thought of a non-evadable one here yet.

Lots of websites used to use Java applets, but browsers decided they're not worth the security risk and made users jump through more and more hoops to start embedded Java.

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

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.

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?

Social media networks are well placed to get their little embedded code snippets updated across the web. And chances are, these links are being generated by a cross-origin javascript library anyway. If you wanted to be very generous, browsers could auto-whitelist origins of every javascript library loaded in the page.

In any remaining cases, there should still be some method to white-list the current behavior, e.g. rel=allowopener.

Reply on news.ycombinator.com