Intent to Implement and Ship: noopener.

[Mike West]

Following up on the suggestion at https://groups.google.com/a/chromium.org/d/msg/blink-dev/rOt3-zVd_T4/A5a6A4MtEAAJ this thread converts that thread's Intent to Implement into an Intent to Implement and Ship. Exciting, eh?

# Contact Emails
mk...@chromium.org

# Spec
https://html.spec.whatwg.org/#following-hyperlinks defines the link relation's behavior (e.g. `<a href="..." target="_blank" rel="noopener">`)

https://html.spec.whatwg.org/#dom-open defines the `window.open` behavior (e.g. `window.open("...", "", "noopener")`).

# Summary
The 'noreferrer' link relation currently governs both referrer policy for a navigation, as well as the 'opener' attribute of any newly created browsing context. The 'noopener' link relation and window feature gives developers the ability to control the latter without opting into the former.

# Motivation
For "Secure Contexts", we'd like to distinguish between popups that are safe to consider "secure", and popups that have to be considered non-secure because they would allow a non-secure context direct DOM access. We can be a little smarter about how we do that, and allow developers to navigate to contexts which ought to be considered secure, if we break the direct relationship between the two windows by dropping `window.opener` and returning `null` from `window.open`.

It's also just a good idea to explain the magic behind `noreferrer` in a way that's exposed to the platform so that the two behaviors aren't tied up together.

# Compatability Risk
Low. This doesn't effect the existing `noreferrer` behavior, and in the worst case, we can just drop it.

Folks at Mozilla seem enthusiastic about the feature (http://logs.glob.uno/?c=mozilla%23content&s=5+Nov+2015&e=5+Nov+2015#c338538 for example), and have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 to track progress.

# Technical Constraints

None.

# OWP Launch Tracking Bug
https://crbug.com/551884

# Link to entry on Chrome Platform Status
https://www.chromestatus.com/feature/5651874132787200

# Requesting approval to ship?

Yes.

-mike

[Darin Fisher]

It's great to see this decoupled.
-Darin

[Anne van Kesteren]

On Fri, Nov 13, 2015 at 3:30 PM, Mike West <mk...@chromium.org> wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 to track progress.

We'd like some closure on https://github.com/whatwg/html/issues/313
ideally. Would be good to nail down exactly the type of isolation this
gives.


--
https://annevankesteren.nl/

[Rick Byers]

So Mike, do you think we should wait on resolving that issue before proceeding with this i2s?

 

--
https://annevankesteren.nl/

[Mike West]

Whatever changes we end up making there will need to apply to the existing `noreferrer` behavior as well as the new `noopener` behavior, so I see it as somewhat orthogonal.

I fully expect that Anne, Boris, and I can hammer out the details and edge cases on that bug in this release cycle. Given that, I'd be fine landing the new keyword to expose the same behavior as our existing `noreferrer` implementation, and then landing the changes to the common behavior. I'd also be find landing the new keyword behind a flag while we work things out if y'all would prefer to be super-safe. :)

-mike

[Rick Byers]

Sounds reasonable to me, I'm confident you all can get consensus on the precise details (and sounds like something we can probably tweak for a bit after ship with minimal risk too).  This seems like a small / low-risk addition to noreferrer  to me.

LGTM1 to ship.

 

-mike

[Dimitri Glazkov]

LGTM2

:DG<

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google