Intent to Ship: Anchor target=_blank implies rel=noopener by default

Skip to first unread message

Eric Lawrence

Oct 19, 2020, 1:29:50 PM10/19/20
to blink-dev
Contact emails


To mitigate "tab-napping" attacks, in which a new tab/window opened by a victim context may navigate that opener context, the HTML standard changed to specify that anchors that target _blank should behave as if |rel="noopener"| is set. A page wishing to opt out of this behavior may set |rel="opener"|.

(As an aside, this change also means that links that specify a scroll-to-text-fragment are more likely to work when shared in web forums, because the scroll-to-text-fragment behavior is only allowed for cross-origin popups when the target is opened noopener).



Blink component

TAG review
None; follows HTML Specification, Safari and Firefox have already implemented.

TAG review status
Not applicable

Interoperability and Compatibility

Scenarios that depend upon pages opened with a target of _blank being able to script their opener will need to explicitly specify |rel="opener"| to avoid |window.opener| being set to null.

Gecko: Shipped/Shipping (

WebKit: Shipped/Shipping (

Web developers: Positive Generally, a security improvement. Security scanners have started to complain about cross-origin hyperlinks that fail to specify noopener:


None; on-by-default.


This change improves security by discarding opener information unless it is explicitly granted.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests? Yes

Tracking bug

Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Mike West

Oct 20, 2020, 1:54:03 AM10/20/20
to blink-dev,

Skipping a TAG review seems reasonable here, as it's behavior that's already shipping in Gecko and WebKit, and is already clearly defined in the HTML spec.

Yoav Weiss

Oct 20, 2020, 2:52:57 AM10/20/20
to Mike West, blink-dev,

This seems like a positive change for security, performance and user experience. Hooray!!

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Daniel Bratell

Oct 22, 2020, 2:42:42 PM10/22/20
to Yoav Weiss, Mike West, blink-dev,

This seems like a typical change that might hurt enterprise sites because they do strange things. Eric, can you please check and see what you think?


Eric Lawrence

Oct 22, 2020, 4:13:42 PM10/22/20
to blink-dev, Daniel Bratell, blink-dev, Eric Lawrence,,
It's indeed true that Enterprises do all manner of strange things.

Correcting a site broken by this change would entail adding a rel="opener" attribute to its links targeting _blank, so it's not a huge cost, but it's obviously not zero either.

Unfortunately, I don't know of a great way to get metrics for this-- we'd have to somehow keep track of whether a given window was targeted to _blank, then count all subsequent accesses against window.opener. I don't know how to do that, or if it's even practical.

Enabling the Standards-compliant/cross-browser behavior by default but offering a time-limited Policy to turn it off probably would not be too expensive (add a policy, plumb it down into the conditional inside HandleClick), although I expect it would probably more than triple the size of the code change. 


Daniel Bratell

Oct 23, 2020, 8:27:13 AM10/23/20
to Eric Lawrence, blink-dev,,

The unique problem for enterprise is that even trivial changes can take months (at least) to go from developer to installation so a time limited policy to revert to the deprecated behaviour sounds like a good plan. I'd support that.

During the API Owner meeting yesterday, we also considered making it possible to turn off remotely but considering that the change is already live in Gecko, I do think a policy is enough protection against breaking things.

LGTM3 with an enterprise policy added.


Eric Lawrence

Oct 23, 2020, 1:00:05 PM10/23/20
to blink-dev, Daniel Bratell,,, Eric Lawrence
Thanks, Daniel.

Based on a similar Blink change[1], I updated my CL[2] with a RuntimeFeature to control the behavior change, and verified that it can be turned off and on. (Based on the [1] CL, I *assume* this capability allows us to disable the change via Finch if we want?)

However, I'm struggling to figure out how to have my RuntimeFeature controlled by policy. 

The Policy docs[3] and RuntimeFeature docs[4] don't seem to cover this case, with the former seemingly describing the process for adding a feature that controls "browser" level behavior. Based on the latter doc, my *assumption* is that what I'd have to do is create a browser pref (in, then use that policy-controlled pref to initialize the blink RuntimeEnabledFeature state [5]. But this seems like a lot of plumbing, and before I go that route I'd like to ensure that I'm on the right track.

Do you know of other policy-controlled Blink features whose CLs I could look at? Or is there any documentation that I've overlooked?

Yoav Weiss

Oct 23, 2020, 2:44:33 PM10/23/20
to Eric Lawrence, blink-dev, Daniel Bratell,

Eric Lawrence

Oct 23, 2020, 3:36:09 PM10/23/20
to blink-dev,, blink-dev, Daniel Bratell,, Eric Lawrence
Thanks, Yoav!

I'd looked at that CL, but this piece in particular felt clunky:

      if (!local_state->GetBoolean(policy::policy_prefs::kUserAgentClientHintsEnabled)) {

It seemed odd to me that we have to invent individual per-feature command-line switches to pass policy configuration into Blink, especially when there's already the |disable-blink-features| switch hanging around. I was especially worried because[6] says "New code should use base::Feature instead of switches." but perhaps the sentence could be expanded with "...although switches are used to pass Feature state between the Browser and Blink"? 

Given that I can only find examples that use bespoke switches, I guess that's what I have to do.

thanks again,

Julian Pastarmov

Oct 26, 2020, 12:24:40 PM10/26/20
to blink-dev,,, blink-dev, Daniel Bratell,, Brandon Heenan
+bheenan FYI 

+1, I think it is wise to back this change by a policy to avoid issues like the ones we have exhibited in the past. 
I am not aware of better ways to pass the policy value in the renderer process then the one suggested by Yoav, although I must admit I don't follow the latest developments in this area closely. You can add me as a reviewer to the policy CLs if you wish.

Also depending on how widespread the issue might be we could expose the feature flag in chrome://flags/deprecated for the life time of the policy if there is evidence that this might need to be set on unmanaged machines more often too. I am not sure if there are useful metrics to guide this decision.


Brandon Heenan

Oct 27, 2020, 3:31:22 PM10/27/20
to Julian Pastarmov, blink-dev,,, Daniel Bratell,
It feels great to have very little useful information to add to the conversation; sounds like we're already planning on having a temporary policy to mitigate enterprise impact, LGTM. To add some color / for those that are interested, we've seen trivial-looking changes take longer than expected because for many enterprises it involves:
  • the admin figuring out which team (possibly a vendor outside of their company) owns the problematic site
  • possibly dealing with prioritization or funding, possibly creating a spec of the change and getting sign off
  • rolling out the change, which may be simple, or may involve scheduled downtime, or fitting into a pre-existing maintenance window
  • in highly regulated or sensitive industries, manual test passes and re-certification of the environment
Reply all
Reply to author
0 new messages