Intent to Implement: 'noopener' link relation.

[Mike West]

# Contact Emails
mk...@chromium.org

# Spec
https://github.com/whatwg/html/pull/290 (and Charlie's https://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts points to the `window.open` syntax I haven't stuffed into a PR yet).

# 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 gives devlopers 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`.

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

That said: I talked to some folks about this at TPAC last week, I haven't heard anything publicly from other vendors; I'm hopeful that this I2I will spawn some responses from folks I've CC'd. :)

# Technical Constraints

None.

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

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

-mike

[Mike West]

(Anne and Boris noted that Scott Beardsley proposed almost exactly this in May on whatwg@, which I apparently need to pay more attention to: https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0046.html. Sorry, Scott!)

-mike

[Scott Beardsley]

Thanks Mike, I closed my PR in favor of yours. I'm glad this issue is getting more attention. I added my comments to the PR. I'm adding Steve Workman from Mozilla since we've discussed this in the past and I believe his team was looking into.

Also even if this proposal is accepted and browsers implement it I'd also like to see some sort of user warning when cross-origin window.opener is modified. That, of course, is a more aggressive stance but if legitimate cross-origin opener modification is rare enough it might be a bigger win to just show the warning.

Scott

[Jeffrey Yasskin]

On Thu, Nov 5, 2015 at 9:58 AM, 'Scott Beardsley' via blink-dev
<blin...@chromium.org> wrote:
> Thanks Mike, I closed my PR in favor of yours. I'm glad this issue is
> getting more attention. I added my comments to the PR. I'm adding Steve
> Workman from Mozilla since we've discussed this in the past and I believe
> his team was looking into.
>
> Also even if this proposal is accepted and browsers implement it I'd also
> like to see some sort of user warning when cross-origin window.opener is
> modified. That, of course, is a more aggressive stance but if legitimate
> cross-origin opener modification is rare enough it might be a bigger win to
> just show the warning.

What would the warning say? Is this something users can understand a
warning about?

Jeffrey

[Scott Beardsley]

Attached is a screenshot of what IE does. BTW, I have a demo page up:

http://hardstatics.com/thrower.html

[Steve Workman]

Thanks for the add Scott. Richard (cc'd) and Dan are both already tagged in the PR and can comment further if needed.

[Jeffrey Yasskin]

Redirecting to Enamel for security UI input. Overall:

* The use of noopener to opt into being a secure context isn't related
to the opener.location security hole, so the following comments don't
apply to Mike's stated goals.

* I'm skeptical of an opt-out attribute to plug a security hole.
* I'm skeptical that users can make an informed decision about "allow
the current website to interact with content from another website".
* If the main risk is that the cross-origin opened page will navigate
the opener without the user noticing, any question should appear when
the user's looking at the navigated page, and should just be enough to
alert them that they're now on a different site. If the current use is
low enough, it might make sense to block cross-origin-opener
navigation entirely.

Jeffrey

On Thu, Nov 5, 2015 at 10:38 AM, Scott Beardsley <sbe...@yahoo-inc.com> wrote:

[Mike West]

Feedback from Mozilla has been strongly positive (http://logs.glob.uno/?c=mozilla%23content&s=5+Nov+2015&e=5+Nov+2015#c338538 for example), the PR cited in the initial email has been merged into the HTML spec, and the change is fairly trivial.

Can I convert this I2I into an Intent to Ship, or would the Powers That Be prefer a separate thread? :)

+Dru for tracking

-mike

-mike

[Chris Harrelson]

Please make a separate thread. This reduces confusion. :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.