Contact emails
bi...@google.com, dom...@chromium.org, emilysc...@chromium.org, aemi...@google.com
Spec
TAG review: https://github.com/w3ctag/spec-reviews/issues/154
For more public discussions on the proposal: https://github.com/WICG/interventions/issues/42
Summary
Adds a new keyword named "allow-top-navigation-by-user-activation" for iframe sandbox, which 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 information, including motivation compared to the existing "allow-top-navigation" keyword, see the intent to implement post.
Link to "Intent to Implement"
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Flt2IixYQK4/RKMfll65AgAJ
Demo link
Is this feature supported on all six Blink platforms?
Yes.
Compatibility Risk
Since this feature is to be opted in by developers, it won’t break any existing content on the web. We considered another option of changing the default behavior of ‘allow-top-navigation’ for sandboxed iframe, but the feedback from Edge convinced us to leave ‘allow-top-navigation’ as a way of getting the full non-sandboxed top navigation behavior.
If we have to remove this feature in the future, it will mean the untrusted third-party content would be unable to trigger a top-level navigation even with user activation.
Interoperability Risk
We have landed web platform tests for this feature through the Chromium auto-export process; see this CL. (Note that some of the tests are necessarily manual tests.)
Edge: public support
Firefox: public support
Safari: no signals
Web developers: positive
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=678759
Entry on the feature dashboard
https://www.chromestatus.com/feature/5629582019395584
Requesting approval to ship?
Yes. Now the keyword of “allow-top-navigation-by-user-activation” is behind a feature flag.
Is the link for "Firefox: public support" correct? That is Boris Zbarsky being worried about the lack of interop in what "user activation" means, and not saying anything about this proposal.
Is the link for "Firefox: public support" correct? That is Boris Zbarsky being worried about the lack of interop in what "user activation" means, and not saying anything about this proposal.Sorry, it's wrong: It should be the next comment from Boris in the thread. Thanks Philip for pointing out.
LGTM3, very nice to see the spec and tests all lined up like this.Is the link for "Firefox: public support" correct? That is Boris Zbarsky being worried about the lack of interop in what "user activation" means, and not saying anything about this proposal.https://github.com/whatwg/html/issues/1903 is now seeing important discussion. Rick, can you take it upon yourself to poke at that issue regularly if needed? I don't think it'd make sense to block on it, but the default is for things like this to fizzle out.
On Mon, Feb 27, 2017 at 5:13 AM, Philip Jägenstedt <foo...@chromium.org> wrote:LGTM3, very nice to see the spec and tests all lined up like this.Is the link for "Firefox: public support" correct? That is Boris Zbarsky being worried about the lack of interop in what "user activation" means, and not saying anything about this proposal.https://github.com/whatwg/html/issues/1903 is now seeing important discussion. Rick, can you take it upon yourself to poke at that issue regularly if needed? I don't think it'd make sense to block on it, but the default is for things like this to fizzle out.If we feel it's important to really improve interop here, I think we'll need more than me poking the issue occasionally (eg. someone probably needs to drive some real research and specific suggests for simplifying our implementation). I filed this bug to track / prioritize the larger issue of driving interop improvements around this.