target=_blank now should default to rel=noopener

[jumde]

https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/

[rebron]

cc: @tomlowenthal can we get prioritization on this one and put in the right milestone, otherwise 1.x Backlog is fine.

[tildelowengrimm]

I think 1.x is right. If someone on the sec team wants to implement sooner that that, it can ride the trains up earlier.

[bershan2]

I'm interested in this issue, if someone specifies how exactly the final algorithm should look like, I will be happy to implement it myself. The following is how I understand this, please correct me if I'm wrong. I'll have to do some testing with all 3 browsers (Safari, Mozilla, Chrome) to see how they behave right now and what's in previews/behind flags. Also, may be, the Chromium itself is a better place for resolving this, e.g. behind a flag and just setting that flag for Brave during compilation?

First of all, this issue mirrors whatwg#4078 and Bugzilla#1503681, which is only only about anchors <a> (Mozilla also did <area> in the same ticket, but reportedly this tag is used so rarely that including it or not should not cause security or compatibility issues[4]). <form> and <base> are covered by a separate issue whatwg#2983. This issue does not deal with window.open().

Here is the tentative summary (please correct me if I'm wrong):

• if no rel is specified, then "disown" the newly created context (window.opener must not be available) [1]
  (This is the new behavior)
• if rel="noopener" is specified, then "disown" the newly created context
  (Old behavior)
• if rel="noreferrer" is specified, then "disown" the newly created context[3]
  (Old behavior)
• if NOT rel="noopener" and NOT rel="noreferrer" and rel="opener", only then make window.opener [1]
  (This is the new behavior. Specifically, rel="noopener" is stronger than rel="opener" no matter how they are ordered[2])

[1] WebKit plan https://trac.webkit.org/changeset/237144/webkit/
[2] Mozilla's tests: https://github.com/mozilla/gecko-dev/blob/master/dom/html/test/browser_targetBlankNoOpener.js
[3] as per current standard behavior

Note that [2] conflicts with comment [3] (just a comment)
[3] whatwg/html#4078 (comment)

[4] whatwg/html#4078 (comment)

Edit: grammar.

[bershan2]

See also: Chromium Issue 898942

[diracdeltas]

bumping to p3 because there are a lot of instances in brave-core where we use target=_blank

[fmarier]

This has landed in Chrome 88: https://bugs.chromium.org/p/chromium/issues/detail?id=898942#c29