1359867 - Add attribute allow-top-navigation-by-user-activation to iframe sandbox

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement, P2)

Description

[Bin Lu]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36




Expected results:

There is a new attribute proposed to iframe sandbox:
https://html.spec.whatwg.org/multipage/browsers.html#attr-iframe-sandbox-allow-top-navigation-by-user-activation

This is a follow-up work of https://bugzilla.mozilla.org/show_bug.cgi?id=1190641

The new attribute requires a user activation (or gesture) being processed to trigger a top-level navigation. 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 could be sandboxed to prevent unexpected malicious behaviors like plugin exploits, auto-redirects, file downloading, modal dialogs, etc). 

For more context:
https://github.com/w3ctag/design-reviews/issues/154
https://github.com/WICG/interventions/issues/42

Comment 1

[Bin Lu]

Demo link (Available in Chrome 58+):
http://w3c-test.org/html/semantics/embedded-content/the-iframe-element/iframe_sandbox_allow_top_navigation_by_user_activation-manual.html

Comment 2

[Boris Zbarsky [:bzbarsky]]

The big problem here, of course, is defining "user activation" in a sane way...

Comment 3

[Bin Lu]

An update: 
In addition to Chrome, Webkit (Safari) has landed CLs to support this: https://bugs.webkit.org/show_bug.cgi?id=171327.
Ad networks have started to use this feature to prevent malicious behaviors (like plugin exploits, auto-redirects, etc) from third-party contents (eg., ads).

It would be great if Firefox could support this soon. Thanks.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Again, the big problem is defining "user activation".  Browsers define it totally differently, and Gecko has at least three different internal definitions I'm aware of.... We'd need to at the very least pick one of those definitions.

Comment 5

[Bin Lu]

Thanks Boris for the reply!
I have no knowledge on how Gecko defines "user activation", but I guess anything reasonable should be fine although browser interoperability would be great. FYI.: Here is a link to how Chromium defines "user activation":
https://docs.google.com/document/d/1mcxB5J_u370juJhSsmK0XQONG2CIE3mvu827O-Knw_Y/edit?ts=59affec4#heading=h.t0ybg8byy7bg

Comment 6

[Ojan Vafai]

We're also working on a proposal for a) simplifying this in Chrome and b) standardizing the new behavior once we've proven to ourselves that it's web compatible. We haven't quite gotten around to sharing it anywhere yet though. Will try to do soon.

Comment 7

[Bin Lu]

Hello, Any update on this?

Ad networks are increasing adopting iframe sandbox, e.g, the % of page views with iframe sandbox has jumped to ~8% from ~0.4% last May (https://www.chromestatus.com/metrics/feature/timeline/popularity/672), and there are also some tech articles talking about this "allow-top-navigation-by-user-activation" attribute now:
https://www.linkedin.com/pulse/can-sandboxing-defeat-redirects-gavin-dunaway/
https://www.peerlyst.com/posts/unsandboxed-ad-iframes-and-content-reco-widgets-are-vulnerable-to-malvertising-attacks-dr-augustine-fou-cybersecurity-ad-fraud-researcher?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BdFXGE2CZQmufZntqTKEgIA%3D%3D

It would be great if Firefox could support it. Thanks.

Comment 8

[dnicol]

Wanted to add my support for this.   

The following browsers support this

We see it working in the following browsers
Chrome for desktop release 58
Chrome for Android release 58
Android WebView release 58
Opera release 45
Opera for Android release 45
Safari Tech Preview 48

It looks like IOS 12 will have this rolled out but we are hoping Apple deploys sooner given the security aspect of the issues.


Force browser redirects is the primary method being leveraged by bad guys to distribute malware and fraud.  Here is a good recent article on a giant network exposed by Confiant https://blog.confiant.com/uncovering-2017s-largest-malvertising-operation-b84cd38d6b85 and another one by GeoEdge http://markets.businessinsider.com/news/stocks/Researchers-at-GeoEdge-uncover-new-Auto-Redirects-Costing-Publishers-and-Marketers-over-1-BillionWith-Auto-Redirects-a-fast-growing-concern-GeoEdge-s-Security-team-uncovered-seven-new-and-1012665863

Comment 9

[Andrew Overholt [:overholt]]

This isn't being actively worked on right now.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

comment 2 and comment 4 are still the main issues here. 

We don't really follow the last step of 
https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation 
I wonder what other browsers do, exactly.
(first two steps are sort of handled https://searchfox.org/mozilla-central/rev/47cb352984bac15c476dcd75f8360f902673cb98/dom/events/Event.cpp#677)

Comment 11

[Mustaq Ahmed]

I /think/ the general idea of "chain of algorithms" in the spec is that anything that is "ultimately" triggered by a user action is treated as such.  For example, a click event handler that sets a timeout function that sends a postMessage... The spec line meant to cover all such cases through this recursive definition.

Chrome maintains and passes on (stack-scoped) UserGestureTokens to allow following the "chain".  But it is far from being complete, sometimes simply because we didn't really get a chance to fix it (e.g. for Promises: crbug.com/404161), sometimes because of implementation complications.  There are cases where we break the chain deliberately; e.g. we don't allow setTimeouts beyond depth 1 perhaps to disallow tricky multiple-popups-per-activation cases.

I doubt if any browsers fully implements the spec.

Currently we are implementing a new simple model ("User Activation v2") where activation states are stored in frames, and propagated up the frame tree (so chaining/stack-scoping won't be needed).  We are fighting regressions now :( .  *If* everything goes well, we plan to propose a new spec (crbug.com/696617).

(A separate thread with MS last month seemed to suggest that Edge does something close to our v2.)

Comment 12

[Boris Zbarsky [:bzbarsky]]

At least some of the "is user activation" bits in Gecko explicitly report "no" if it's been too long such that users would not perceive the thing that happens as a response to their action.

Comment 13

[Bin Lu]

Olli, Thanks for looking into this.
Have Mustaq and Boris's explanations answer your question?
Is there any other concerns/blockers on implementing this? Thanks.

Comment 14

[Boris Zbarsky [:bzbarsky]]

The concern is the same as it was all along: definition of "user activation".

Comment 15

[Domenic Denicola]

The spec has a definition. It's known not to be perfect (https://github.com/whatwg/html/issues/1903), and Chrome is investing some resources into working on that.

But I am hopeful that in the meantime that browsers are still willing to ship features that take advantage of user activation, just like they've done with e.g. the notifications API, the credential management API, service workers' clients API, recent work to move the vibrate API behind user activation, etc. (https://www.google.com/search?q=%22triggered+by+user+activation%22+site%3Agithub.io seems informative.)

In other words, I'm not sure why this feature in particular would be held up by trying to perfect the definition of user activation, when Firefox has shipped many other features based on it.

Comment 16

[Boris Zbarsky [:bzbarsky]]

The real question is to what extent we need to worry about compat fallout.  That needs to be decided on a case-by-case basis.  Navigation not working is obviously a bigger compat problem than notifications not working, for example.

But yes, we can of course just ship something and then hope that we don't break too many sites when we end up changing behavior later.  That still requires us deciding what the "something" we ship is, because Gecko has multiple different concepts that sort of look like "user activation", as I said above.  And that needs someone with time to sit down and think about how this will be used in practice and which of those concepts best maps onto the use cases.

Comment 17

[Mustaq Ahmed]

Two points re the "user activation" worries:

- For popups in major browsers, we hardly found any consistency from this perspective: https://docs.google.com/presentation/d/1vilDD2x__CXOV5kAPmhUCzgsVAkFt5fxsnT4AqlP8KU/edit#slide=id.g242f4237e9_0_74

- Since you mentioned the need for a thorough look: in Chrome we are doing exactly that today.  For User Activation v2, our end goal is to replace Chrome's hacky old system with one that simple enough for cross-browser implementation.  Feel free to comment on our design: https://docs.google.com/document/d/1erpl1yqJlc1pH0QvVVmi1s3WzqQLsEXTLLh6VuYp228/edit?usp=sharing

Comment 18

[dnicol]

Received confirmation from Microsoft team that this is now in their dev queue.  Would really love to see a path forward.

Comment 19

[Andrew Overholt [:overholt]]

It seems like the biggest hangup here is lack of clarity around "user activation". What specific questions do we need answered? Should we check with the Edge team on what they are planning on doing? Or is it just like Boris says in comment 16 that someone needs to sit down and think about it?

Comment 20

[Boris Zbarsky [:bzbarsky]]

I think we just need to sit down and think about it, though checking what other UAs are doing could be useful input, sure.

Comment 21

[Edgar Chen [:edgar]]

AFAIK, 
1. Most of user-activation in Gecko is based on whatever EventStateManager::IsHandlingUserInput[1] returns. And it treats key events (except Esc, Shift, Ctrl, Alt ..), mouse events and pointer events as user input. (Spec treats contextmenu as user-activation, but Gecko doesn't)
2. The user-activation for Fullscreen adds 1000ms timeout [2].
3. The user-activation for popup has a whitelist [3] + all access key [4].

[1] https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/dom/events/EventStateManager.cpp#4121
[2] https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/dom/base/nsContentUtils.cpp#7120-7125
[3] https://searchfox.org/mozilla-central/rev/f2ac80ab7dbde5400a3400d463e07331194dec94/modules/libpref/init/all.js#1248
[4] https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/dom/html/nsGenericHTMLElement.cpp#2544

Comment 22

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

See https://www.admonsters.com/can-sandboxing-defeat-redirects/ for motivation. "While Chrome (versions 58 and later) has enabled the control, Firefox, Safari, and Internet Explorer prior to 10 have not."

Comment 23

[Bin Lu]

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #22)

See https://www.admonsters.com/can-sandboxing-defeat-redirects/ for motivation. "While Chrome (versions 58 and later) has enabled the control, Firefox, Safari, and Internet Explorer prior to 10 have not."

Just a clarification: Safari has supported this on both Mac & iOS since April 2018: https://bugs.webkit.org/show_bug.cgi?id=171327, which is also mentioned above.

So with Edge moving to use Chromium, Firefox would be the only major browser not supporting this.

Comment 24

[Ian Dunn]

FWIW, here's an example of where another major open source project could take advantage of this if it existed, which would improve UX for millions of users:

https://core.trac.wordpress.org/ticket/39097#comment:19

Comment 25

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1359867 - Add support for allow-top-navigation-by-user-activation iframe sandboxing r?smaug

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1a75435c9764
Add support for allow-top-navigation-by-user-activation iframe sandboxing r=smaug

Comment 27

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23888 for changes under testing/web-platform/tests

Comment 28

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 29

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 30

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/1a75435c9764

Comment 31

[Chris Mills [:cmills]]

Docs work completed; see https://github.com/mdn/sprints/issues/3414#issuecomment-652566772 for the full details.

The MDN iframe page already describes the new token nicely, so there was not much to do here.