Intent to implement and ship: Require user gesture for sandboxed iframe w/ 'allow-top-navigation' to navigate top-level page

[Emily Schechter]

Contact emails
bi...@google.com, oj...@chromium.org, mk...@chromium.org, kenji...@chromium.org, emilysc...@chromium.org, aemi...@google.com

Spec
Public standards discussion: https://github.com/WICG/interventions/issues/42

Summary
Require user gesture for sandboxed iframe w/ 'allow-top-navigation' to navigate top-level page, and the top-level navigation will be blocked if there is no user gesture. This change would enable more use cases of sandboxing untrusted third-party contents (eg., ads) by allowing top navigation while blocking malicious auto-redirecting, and thus help building a safer internet (eg., a safer ads ecosystem in which all ads are sandboxed to prevent unexpected malicious behaviors like plugin exploits, auto-redirects, file downloading, modal dialogs, etc).

Motivation
Iframe sandbox has been used on securing untrusted third-party contents (eg., ads) on web sites, which could eg., disallow top-level navigation or block plugin from loading (and thus prevent popular plugin exploits using vulnerabilities of Flash, Silverlight, PDF, etc).

However, iframe sandbox either blocks all (including user-gesture-triggered) top-level navigation or allow all kinds of top-level navigation with "allow-top-navigation" including auto-redirecting w/o user gesture (which has been heavily abused eg., by malicious ads). This has prevented iframe sandbox from being more widely used to protect users eg., by those ads navigating top-level page after user click which is unfortunately quite common in the current ads ecosystem.

This has a similar purpose to another effort (which is still in an experimental stage): "Require a user gesture for a cross-origin frame to navigate the top-level page" (github link, intent email), but complementary to it, since this would cover different use cases and might break less pages and thus less risky.

Compatibility Risk

Per UseCounter, an <iframe> navigates its top browsing context on 0.017% of page loads. We still need to collect (work-in-progress) the metrics on what percentages of these navigations are from sandboxed iframe w/ 'allow-top-navigation' & w/o a user gesture, but it is considered a low risk change since it should affect much less pages than the other effort on requiring user gesture on cross-domain iframe.

Another option we discussed is to add a new flag called say "allow-top-navigation-with-gesture" for opt into this intended behavior (or a new flag called say "allow-top-navigtion-without-gesture" to opt out this), but this one of changing the default behavior of "allow-top-navigation" is preferred since it's simpler & less confusing to developers. But if this breaks many pages, we should revisit the other option of adding a new flag.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=678759

https://www.chromestatus.com/feature/5629582019395584

Requesting approval to ship?
Yes, initially as a Finch trial behind a feature flag.

[Rick Byers]

Intuitively it feels like this is probably pretty safe and a good thing to do, but I think we need some more compat data before we give it a try.  We've just decided to postpone the related intervention because it broke a bunch of login and payment sites.  Eg. do we have UMA stats on what fraction of page visits involve a sandboxed iframe with allow-top-navigation set?

We should probably treat this as a "deprecate and remove" for the purposes of our blog posts for breaking changes.  Joe, do you look for all the launch bugs with OWP-Type-ChangeAPI or just OWP-Type-Deprecation?  Or do you use the, unfortunately somewhat redundant, data from chromestatus?

Can we report a console warning in this case for at least a milestone ("deprecate") before we change the behavior ("remove")?

We should [get the discussion started](https://github.com/WICG/interventions/issues/42#issuecomment-270771453) on whether it's reasonable to consider updating the HTML5 spec for this.

Rick

[Joe Medley]

On Thu, Jan 5, 2017 at 2:08 PM, Rick Byers <rby...@chromium.org> wrote:

Joe, do you look for all the launch bugs with OWP-Type-ChangeAPI or just OWP-Type-Deprecation?  Or do you use the, unfortunately somewhat redundant, data from chromestatus?

None of the above. I have an inbox filter that tags Chrome intents. Then I make sure I subscribe to the tracking bug so that I can make sure it gets noted on Chrome Status when it's finished. 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Joe Medley]

Or sooner, preferably.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Bin Lu]

Thanks Rick and Joe for the replies.

.. we need some more compat data before we give it a try.  Eg. do we have UMA stats on what fraction of page visits involve a sandboxed iframe with allow-top-navigation set?

Just submitted a CL to collect metrics on the % of page views that do top navigations in sandboxed iframes w/ or w/o 'allow-top-navigation' and user gesture.

It should give us a good idea on the risk of this change although it's supposed to be quite low.

 

Can we report a console warning in this case for at least a milestone ("deprecate") before we change the behavior ("remove")?

Since we will do it as a Finch trial behind a feature flag, how about we turn it off by default and turn it on later when we have collected data to confirm the risk is low?

This might save us a release cycle since we'd like this to be shipped fast so we can experiment in our ads implementation.

Make sense?

Thanks,

Bin

[Rick Byers]

On Fri, Jan 6, 2017 at 5:49 PM, 'Bin Lu' via blink-dev <blin...@chromium.org> wrote:

Thanks Rick and Joe for the replies.

.. we need some more compat data before we give it a try.  Eg. do we have UMA stats on what fraction of page visits involve a sandboxed iframe with allow-top-navigation set?

Just submitted a CL to collect metrics on the % of page views that do top navigations in sandboxed iframes w/ or w/o 'allow-top-navigation' and user gesture.

It should give us a good idea on the risk of this change although it's supposed to be quite low.

 

Can we report a console warning in this case for at least a milestone ("deprecate") before we change the behavior ("remove")?

Since we will do it as a Finch trial behind a feature flag, how about we turn it off by default and turn it on later when we have collected data to confirm the risk is low?

This might save us a release cycle since we'd like this to be shipped fast so we can experiment in our ads implementation.

Make sense?

Can you add a deprecation message as well now so that even with the trial off, there's warning that something is expected to break?

Perhaps you want to have the finch config setup to keep it enabled (at least at 50%) in canary and dev channel (no launch approval necessary AFAIK) to help collect the other sort of compat data?  I'm guessing the metrics will be low but not so tiny as to eliminate the compat concerns completely (afterall, there is active abuse we're trying to disable - right?).  If that's true then we probably won't want to flip it on late in beta or something - we rely on some exposure during beta to help collect reports of issues from the wild.

The main thing that would buy us time is merging the new metrics / deprecation warning back to M56, but perhaps it's too late for that now?

[Bin Lu]

Thanks Rick!

 

Can you add a deprecation message as well now so that even with the trial off, there's warning that something is expected to break?

Sure, I will add it asap.

 

Perhaps you want to have the finch config setup to keep it enabled (at least at 50%) in canary and dev channel (no launch approval necessary AFAIK) to help collect the other sort of compat data? 

Glad to know! I will do it.

 

I'm guessing the metrics will be low but not so tiny as to eliminate the compat concerns completely (afterall, there is active abuse we're trying to disable - right?).  If that's true then we probably won't want to flip it on late in beta or something - we rely on some exposure during beta to help collect reports of issues from the wild.

The main thing that would buy us time is merging the new metrics / deprecation warning back to M56, but perhaps it's too late for that now?

Yeah, make sense to me. It might be too late for M56, and I'm thinking M57.

Thanks,

Bin

[Bin Lu]

Can you add a deprecation message as well now so that even with the trial off, there's warning that something is expected to break?

Send out a CL: https://codereview.chromium.org/2617313002/. 

Does it look good?

BTW: The link mentioned above for the CL to collect metrics was wrong, and the correct one is: https://codereview.chromium.org/2614073004.

The main thing that would buy us time is merging the new metrics / deprecation warning back to M56, but perhaps it's too late for that now?

Would it still be possible to merge them back to M56? Maybe together with the CL on postponing the related intervention?

 

Thanks,

Bin

[Bin Lu]

I'm guessing the metrics will be low but not so tiny as to eliminate the compat concerns completely (afterall, there is active abuse we're trying to disable - right?).  If that's true then we probably won't want to flip it on late in beta or something - we rely on some exposure during beta to help collect reports of issues from the wild.

I'm rethinking about this: The traffic of the active abuse we're trying to disable hasn't been sandboxed yet (i.e., won't bring more compat issues) since those ads (e.g, AdSense or DFP ads) do navigate the top level page after user click. And this feature will enable us to sandbox them with 'allow-top-navigation' while preventing auto-redirecting from them.

Thanks,

Bin

[Chris Harrelson]

Hi,

What's the status of this intent? I'm a bit unsure what the latest plan or request is.

--
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+unsubscribe@chromium.org.

[Bin Lu]

It's still being discussed internally:

The CL for collecting metrics has been merged back in M56, but the one for adding deprecation message has been hold back since Ojan proposes to go back another option of adding another sandbox flag 'allow-top-navigation-with-user-gesture' (to allow top navigation only with gesture), in order to avoid breaking existing content & providing stricter protection.

But some concerns were raised before that two top navigation-related values for sandbox might be confusing to developers, e.g., 

- Should "allow-top-navigation-with-user-gesture" always be used together with "allow-top-navigation" (Like 'allow-popups-to-escape-sandbox' to 'allow-popup')? If yes, it'd be very confusing; If not (i.e., it should be used separately from "allow-top-navigation"), what will happen if developers set both? Just ignore "allow-top-navigation-with-user-gesture" and allow any kind of top navigation including auto-redirecting? Or only allow top navigation with user gesture?

What do people think?

[Bin Lu]

After more discussions, the new proposal preferred by people is to add a new flag named "allow-top-navigation-by-user-activation" for iframe sandbox, which requires a user activation (or gesture) being processed to trigger top-level navigation. The requirement of a user activation being processed for top navigation would be more restricter than that of requiring having ever a user activation in the past in the original proposal (which was a compromise to minimize compatibility issues originally from https://github.com/WICG/interventions/issues/16).

It will be completely safe from a compatibility perspective & would provide better protection than the old requirement in the original proposal, although it's a little more complex than having only a single option about top navigation ('allow-top-navigation'). "allow-top-navigation-by-user-activation" would be redundant (a subset of) "allow-top-navigation", so people would generally only specify one or the other (but if both are specified, that's presumably indistinguishable from specifying 'allow-top-navigation' alone).

How do people think? Any strong objection?

[Lucas Ballard]

SGTM

[Rick Byers]

Yep that sounds perfect to me, thanks.

We should see if we can get this added to the html spec (or if necessary some temporary monkey-patch spec in WICG) and then do an updated "intent to ship".

In the interim (absent objections from anyone else) feel free to start implementing behind a status=experimental RuntimeEnabledFeature.

[Chris Harrelson]

Sounds good to me to, FWIW.

[bi...@google.com]

Just an update since someone just pinged me about this: 

This has been replaced by “allow-top-navigation-by-user-activation” iframe@sandbox keyword. 

See https://groups.google.com/a/chromium.org/d/msg/blink-dev/El0ueyoNgRE/N-6u2SdNDgAJ.

SGTM

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

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