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

[Eric Lawrence]

Contact emails
eri...@microsoft.com

Summary

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

Explainer
https://html.spec.whatwg.org/#following-hyperlinks

Specification
https://html.spec.whatwg.org/#following-hyperlinks

Blink component
Blink>DOM

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

TAG review status
Not applicable

Risks

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 (https://bugzilla.mozilla.org/show_bug.cgi?id=1522083)

WebKit: Shipped/Shipping (https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/)

Web developers: Positive Generally, a security improvement. Security scanners have started to complain about cross-origin hyperlinks that fail to specify noopener: https://bugs.chromium.org/p/chromium/issues/detail?id=898942#c21

Ergonomics
None.


Activation
None; on-by-default.


Security

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 https://crbug.com/898942

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/6140064063029248

This intent message was generated by Chrome Platform Status.

[Mike West]

LGTM1.

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]

LGTM2

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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa05b5eb-3df9-4530-a278-0c3ad640bd85n%40chromium.org.

[Daniel Bratell]

This seems like a typical change that might hurt enterprise sites because they do strange things. Eric, can you please check https://www.chromium.org/developers/enterprise-changes and see what you think?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiGyEOqsk-2PCsXgN8jmZ5yeSCrdNKoVE%3DQLfUzH0dPtA%40mail.gmail.com.

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

WDYT?

[Daniel Bratell]

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.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e1c2c34-ff2a-442f-b46b-42c24fee195fn%40chromium.org.

[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 browser_prefs.cc?), 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?

thanks!

[1] https://chromium-review.googlesource.com/c/chromium/src/+/2216701

[2] https://chromium-review.googlesource.com/c/chromium/src/+/1630010/9

[3] https://chromium.googlesource.com/chromium/src/+/master/docs/enterprise/add_new_policy.md

[4] https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md

[5] https://chromium.googlesource.com/chromium/src/+/master/docs/initialize_blink_features.md

[Yoav Weiss]

https://chromium-review.googlesource.com/c/chromium/src/+/2248426 might be a good example.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7fc22942-dee5-4ae4-89fc-8c7c36b2878cn%40chromium.org.

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

        command_line->AppendSwitch(blink::switches::kUserAgentClientHintDisable);

      }

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 Configuration.md[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,

-E

[6] https://chromium.googlesource.com/chromium/src.git/+/207cebd23af676aea31fdb345bba00158ced311d/docs/configuration.md

[Julian Pastarmov]

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

Thanks,

Julian

[Brandon Heenan]

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