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

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
P2
enhancement
a year ago
a month ago

People

(Reporter: Bin Lu, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
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
(Reporter)

Updated

a year ago
Component: Untriaged → DOM: Security
Product: Firefox → Core
The big problem here, of course, is defining "user activation" in a sane way...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → enhancement
Component: DOM: Security → DOM: Core & HTML
Priority: -- → P2
(Reporter)

Comment 3

10 months ago
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.
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.
(Reporter)

Comment 5

10 months ago
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

10 months ago
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.
(Reporter)

Comment 7

5 months ago
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.
Flags: needinfo?(overholt)

Comment 8

5 months ago
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
This isn't being actively worked on right now.
Flags: needinfo?(overholt)
Keywords: dev-doc-needed

Comment 10

4 months ago
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

4 months ago
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.)
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.

Updated

4 months ago
Blocks: 1419262
(Reporter)

Comment 13

4 months ago
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.
Flags: needinfo?(bugs)
The concern is the same as it was all along: definition of "user activation".

Comment 15

4 months ago
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.
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

4 months ago
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

3 months ago
Received confirmation from Microsoft team that this is now in their dev queue.  Would really love to see a path forward.
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?
Flags: needinfo?(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.
Flags: needinfo?(bzbarsky)
You need to log in before you can comment on or make changes to this bug.