Intent to Implement: Block modal dialogs inside sandboxed documents.

[Mike West]

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

Do we support onbeforeunload events from iframes? if yes, should we also ignore them here?

[Mike West]

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]

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]

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]

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]

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