Add a new 'allow-top-navigation-by-user-activation' flag to iframe sandbox to require a user activation for top-level page navigation

[lubin2010]

The proposal: With the "allow-top-navigation" flag, sandboxed iframe should allow top-level navigation only when there is/has even been user gesture on the sandboxed iframe. This change would enable use cases of allowing top navigation while blocking malicious auto-redirecting from third-party resources, which would enable sandboxing & securing more untrusted contents 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).

More context: 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.

[bzbarsky]

Is there a clear definition of "user gesture" that is not browser-specific?

[lubin2010]

This is related to issue #16: "Require a user gesture for a cross-origin frame to navigate the top-level page" (which is still in the experimental stage) but complementary to it, since this would cover some other cases (e.g. #16 doesn't cover all sandboxed iframes with "allow-top-navigation") and might break less pages and thus less risky.

[lubin2010]

@bzbarsky, thanks for the question. /cc @ojanvafai @mikewest for comments.

[chrisbro-MSFT]

@lubin2010, thanks. A little concerned that this issue adds a new type of restriction to sandboxed iframes without a corresponding way to choose to disable it. So there's still a compat risk, much smaller than #16, but with no workaround other than to disable sandboxing.

I'm ignorant of how the advertising landscape typically works, though. Does the site owner usually iframe the ad site directly or do they just pull in a script that then creates the iframe? If it's the latter than their script could just add the token which would make this meaningless, but of course then they wouldn't sandbox the frame at all, so I guess it's the former?

[lubin2010]

@chrisbro-MSFT Another option of adding a new flag (eg., called "allow-top-navigation-with-gesture" or "allow-top-navigtion-without-gesture") was discussed but this one was preferred since it's simpler & less confusing to developers. Do you see any use cases that would require sandboxed iframe (mostly with untrusted contents eg., ads) to auto-navigate top-level page w/o any user gesture?

For the ads scenario, the site owner usually pull in a script from an ads network which is responsible for creating the ads iframe & possibly sandboxing it. Since both site owners & ads networks want to prevent malicious ads, the ads networks have incentives to sandbox ads iframe whenever possible (or when there is a reasonable way to make it work).

[chrisbro-MSFT]

Hmm. The other thread had a few examples but they seem workable aroundable. I think most apps should try to sandbox everything that they can and only turn on the features they need, and that gets harder if you can't tweak some of the options, but this seems like a relatively safe change.

[RByers]

Is there a clear definition of "user gesture" that is not browser-specific?

@bzbarsky, the situation is getting better but we still don't have great interop. We should probably now use the term "triggered by user activation" to match the spec instead of the blink implementation term "user gesture" but for now they should be considered synonyms.

@domenic / @mikewest if we can show this is web compatible, would it be reasonable to try to specify this behavior? @lubin2010 perhaps you want to file an issue on the HTML spec for this. As usual for interventions, I don't think we should worry about getting a spec change fully reviewed and landed until we can prove it's actually web compatible.

[domenic]

We definitely should try to specify this. The most immediate question to me is whether this should be a "may" or a "must". I.e. would we prefer to change the meaning of allow-top-navigation to normatively mean "allow top navigation only with user activation", or do we just add some clause that allows browsers to use signals (perhaps specifically calling out user activation as an example) to disallow top navigation even with allow-top-navigation set?

[lubin2010]

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 #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?

[domenic]

I've specced @lubin2010's latest proposal at https://github.com/whatwg/html/pull/2292. We won't merge it until there are clear multi-vendor signs of interest however, so if there is indeed multi-vendor support, please let us know, either here or there.

[domenic]

@chrisbro-MSFT do you have thoughts on the new proposal?

[chrisbro-MSFT]

As an opt-in proposal this sounds great. For our scenarios we would ask partners not to enable this flag, and the other scenarios that people have (APIs driven in hidden iframes) also have no compat risk because they just won't enable the flag on their iframes either.