About rel=noopener (2016) | Hacker News Reader

About rel=noopener (2016)

mathiasbynens.github.io

108 pointsedance46 comments

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.

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.

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.

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.

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.

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.

Content-Security-Policy might be a good way to opt in to this kind of behavior.

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

HTML 2.0 was published in 1995.

I doubt this behaviour comes purely under html anyway as its only usable from the javascript environment.

More likely is a content security policy... oh looke there: https://w3c.github.io/webappsec-csp/#directive-disown-opener

I'm aware of that - the existing HTML versions have been pretty much incremental though. XHTML was a breaking change but more for syntactical reasons. By a "2.x" version I mean a fresh rewrite with no requirements for parity with previous versions, so the lessons of the current engine can be applied in a clean-slate environment.

i feel like there must be an xkcd that sums up your suggestion...

https://xkcd.com/927/

Or mobile: https://m.xkcd.com/927/

I'm not sure that applies here but it could definitely suffer from the Second System Effect - https://en.wikipedia.org/wiki/Second-system_effect

> in semantic versioning terms, we need a "2.x" of the HTML API.

Version # is not the phrase you want to overload. HTML5 is the latest version and was released 4 years ago.

I'm not suggesting overloading it - just trying to come up with a fitting metaphor.

How about a Babel-like transpiler, that would take HTML written in this newly proposed standard and outputs backward-compatible code? For example, adding rel="noopener" by default to external links.

This could work, but ultimately it's just more and more duct tape. It's high time to start with a cleaner, more secure slate and let people migrate maintained applications over; the old stuff can run in a more secured, more limited sandbox.

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

That does nothing for deployed sites that aren't actively developed? Browser devs have decided those sites are worth not breaking.

Browsers should show a warning that a "possibly insecure legacy mode" is in use.

If browsers enforce HTTPS in a similar way, I don't see why they shouldn't enforce better security elsewhere as well.

According to https://jakearchibald.com/2016/performance-benefits-of-rel-n... edge doesn't set window.opener for blank links so I'd assume it's not being used that much. I mean, it's Microsoft, they usually go out of their way to be backwards compatible.

Just warn them that at some point in time the feature will cease to work. I see these warnings in the console all the time for broken SSL CAs and deprecated DOM APIs.

Seems like the simple solution would be for those apps to include something like “rel=yesopener” on the link to the payment provider, as a way to explicitly opt into the functionality.

Browsers deprecate security related features all the time. See SSL, HSTS [EDIT: HPKP*], etc.

At the very least, browsers could remain backward compatible but mark the URI as “Insecure” in the address bar if the link could result in tab hijacking. Although on second thought, that would be challenging because it would require parsing the source of all links.

HSTS is not deprecated, HPKP is.

HSTS is what tells the browser "this website MUST be served over TLS".

HPKP is what tells the browser "this website must be served over TLS with this exact key".

HPKP is being deprecated due to the large "footgun" it creates for websites, and the difficulty at actually managing it. It's being replaced by "Expect-CT" which is a much easier and safer way of getting a similar result.

As well as a footgun, HPKP (and any similar pinning technology) unavoidably creates opportunities to take sites hostage. If the current owner of site X can say "Only trust this site if key K is involved in the trust chain" then if bad guys are able to take over the site even briefly, and say "Only trust this site if key J is involved" instead, they can sell you key J for however much you value your site. Without it, nobody in the world can "get back" your site in reasonable time, no court order, no service provider, nothing else will work. They can even choose to do this, then destroy key J, now your site is bricked and nobody can fix that.

Expect-CT is very different, I'm not sure "similar result" is the right phrase. HPKP lets you pin to any set of keys, a reasonable choice might be your current key, a spare key that your DevOps have ready to go, and one more that's printed out on a piece of paper in the company safe labelled "important: Web site private key, never lose this".

Expect-CT is like Python's from future import, in the future we expect the Web PKI to use Certificate Transparency logging policy to ensure oversight over all CAs. Expect-CT lets you demand enforcement of such policy today, to the extent that's possible. Today policy is still in a state of flux, so enforcing it might not do what you expect, whereas HPKP was very predictable. On the other hand, it's definitely not subject to hostage taking, and it's probably less susceptible to footguns, so that's nice. And if the future does come to pass as expected it's future proof, since such a policy will become de facto the normal behaviour of common user agents.

[Edited to make more sense]

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

Here's one for Chrome: https://chrome.google.com/webstore/detail/no-opener-no-phish...

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

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

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

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

That page says the opposite of what you just said.

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

I think this is largely a non-issue now due to spectre mitigations. e.g. Chrome is enabling site-isolation by default which would run the new page in a separate process anyway. I think the other major browsers are also doing something similar.

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

Why has this post been flagged?

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

But have you truly internalized it?

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

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.

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

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

Hehe I was kidding. I’ve only sort of internalized it.

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 there should be a repository called mathiasbynens.github.io right? But I can't find it.

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

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

The article is two years old but still up-to-date. The links to the relevant browser bugs are in the document, and the Edge bug is still unresolved. https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...

Reply on news.ycombinator.com