Intent to Implement: Block modal dialogs inside sandboxed documents.

764 views
Skip to first unread message

Mike West

unread,
May 18, 2015, 6:27:18 AM5/18/15
to blink-dev
# Contact emails
mk...@chromium.org

# Spec
Just mailing list conversation at https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0035.html; I'm hopeful we can get it into HTML if folks think it's a reasonable addition.

# Summary
`alert()`, `confirm()`, `prompt()`, and `print()` will no longer have any affect inside sandboxed documents; they will instead synchronously return a reasonable default value (`false` for `confirm()`, and `null` for `prompt()`) without prompting the user.

# Motivation
Folks in Google's anti-malvertising team would like to be able to prevent sandboxed frames from popping up confusing, modal messages to users. Ideally, we could simply block those entirely inside sandboxed frames (as Hixie vaguely suggested in https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html). I suspect that the numbers will be low enough to make that change without much risk (sandboxing itself is hovering around 0.6% of page loads: https://www.chromestatus.com/metrics/feature/timeline/popularity/672).

If the numbers are higher than I expect, we could add something like an `allow-modals` sandbox flag to support turning the feature back on.

# Compatibility Risk
Firefox: No public signals
Internet Explorer: No public signals
Safari: No public signals
Web developers: Positive

# Describe the degree of compatibility risk you believe this change poses
Browsers that support sandboxing but don't support this feature will be a bit of a problem, as there's no clear way to feature-detect sandboxing characteristics of a browser. Until such a thing exists, web developers would almost certainly need to resort to UA sniffing, which is fairly ugly.

Suggestions regarding detection possibilities are welcome. :)

# Ongoing technical constraints
None.

# Will this feature be supported on all six Blink platforms
Yes.

# OWP launch tracking bug
https://crbug.com/483624

# Link to entry on the Chromium Dashboard
https://www.chromestatus.com/features/4747009953103872

# Requesting approval to ship?
No.

-mike

Jochen Eisinger

unread,
May 18, 2015, 6:30:21 AM5/18/15
to Mike West, blink-dev
Do we support onbeforeunload events from iframes? if yes, should we also ignore them here?

Mike West

unread,
May 18, 2015, 6:33:39 AM5/18/15
to Jochen Eisinger, Brad Hill, blink-dev
On Mon, May 18, 2015 at 12:30 PM, Jochen Eisinger <joc...@chromium.org> wrote:
Do we support onbeforeunload events from iframes? if yes, should we also ignore them here?

We probably still do, and yes, we should also ignore them here.

Folks have also suggested ignoring basic auth dialogs as well (where by "ignoring", I mean "cancelling the request"). I haven't poked at that yet, but it also seems reasonable to me (+Brad Hill, who suggested this on the whatwg@ list).

-mike

Philip Jägenstedt

unread,
May 18, 2015, 8:25:34 AM5/18/15
to Mike West, Jochen Eisinger, Brad Hill, blink-dev
This sounds like a good idea. Hixie said about auth dialogs that he's "actually rather surprised that browsers still show these for iframed content." It might be worth measuring how common this is, to possibly ignore such dialogs for all iframes, sandboxed or not?

Philip

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

Brad Hill

unread,
May 18, 2015, 2:22:35 PM5/18/15
to Philip Jägenstedt, Mike West, Jochen Eisinger, blink-dev
I believe it has been attempted before (perhaps not by Blink) to block auth dialogs for all iframes and resource loads, and it broke enough things that it was backed out.  Sandboxed iframes seem like a safe place to be aggressive.

Rob Wu

unread,
May 20, 2015, 10:36:20 AM5/20/15
to Brad Hill, Philip Jägenstedt, Mike West, Jochen Eisinger, blink-dev
Please do add an opt-in like allow-modals before blocking alert/confirm/prompt by default. The current feature request makes much sense for third-party adverts, but less so for code snippet sites like JSFiddle and Stack snippets. Modal dialogs are invaluable for small code demos to show results. I expect many code snippets to fail if modals are blocked by default.

So far the replies about auth dialogs referred to frames, but keep in that the sandbox directive can also be applied to top-level frames via the sandbox directive of the Content-Security-Policy response header. So even if the current practice is that auth dialogs are already blocked in iframes, explicitly forbidding it still makes sense for top-level frames.

Kind regards,
 Rob
 https://robwu.nl

Mike West

unread,
May 23, 2015, 3:19:09 AM5/23/15
to Rob Wu, Brad Hill, Philip Jägenstedt, Jochen Eisinger, blink-dev
FYI: https://codereview.chromium.org/1126253007 landed, introducing
the new behavior and `allow-modals` to revert to status quo. It
doesn't yet block auth dialogs or onbeforeunload, but you should be
able to play with the core of the idea in an upcoming canary (behind
the experimental web platform features flag).

-mike
-Mike
Reply all
Reply to author
Forward
0 new messages