Re: [whatwg] Proposal: Two changes to iframe@sandbox

>
> 1. Block modal dialogs from inside sandboxed frames. That is:
> * `alert(...)` would return without popping up a dialog.
> * `confirm(...)` would return `false` without popping up a dialog.
> * `prompt(...)` would return `null` without popping up a dialog.
> * `print(...)` would return without popping up a dialog.


I'm OK with that.  As a general rule, though, I would prefer that pretty
much whatever gets blocked by default can be reenabled via additional new
keywords (e.g. "allow-modals").  Although I understand the rational for
blocking native plugins by default due to their inherent unmanaged nature,
I still wish that they could be reenabled via a keyword as there are still
realistic scenarios where you may want (e.g.) Flash enabled but still
disallow/disable other features like popups, navigation, etc.


2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to create
> clean browsing contexts, unaffected by the sandbox which spawned them.


I'm OK with that, too.  I'm assuming that cascades, though, right?  In
other words, if the top window does NOT use the
"allow-unsandboxed-auxiliary" keyword on its child iframe, I'm assuming the
child iframe cannot successfully use "allow-unsandboxed-auxiliary" on a
child iframe of its own.

Sincerely,
    James Greene


On Sun, May 10, 2015 at 11:11 PM, Mike West <mkwst@google.com> wrote:

> (BCC: public-webappsec@w3.org)
>
> Hello, wonderful whatwg@ folks!
>
> I've talked with a few folks from Google's advertising teams who are
> interested in using sandboxed iframes to mitigate the risks associated with
> ads. They've flagged two things that they'd like to see happen in the
> future:
>
> 1. Block usage of `alert()` (and its friends `confirm()`, `prompt()`, and
> `print()` (and `showModalDialog()` for browsers that support it)).
>
> 2. Allow sandboxed frames to spawn new windows without forcing the sandbox
> upon them. This would allow the advertisement itself to be sandboxed,
> without forcing the same restrictive flags upon a landing page.
>
> # Proposal
>
> 1. Block modal dialogs from inside sandboxed frames. That is:
>
> * `alert(...)` would return without popping up a dialog.
> * `confirm(...)` would return `false` without popping up a dialog.
> * `prompt(...)` would return `null` without popping up a dialog.
> * `print(...)` would return without popping up a dialog.
>
> This was discussed briefly at
>
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html
> ,
> but I didn't find any follow-up (CCing folks from that thread). I've added
> metrics to Chrome in https://codereview.chromium.org/1121053002, but it
> will take a few weeks to get good data. Given the low usage of sandboxes in
> general (~0.5% of page views, according to
> https://www.chromestatus.com/metrics/feature/timeline/popularity/672), I
> suspect we could fairly easily make this change.
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to create
> clean browsing contexts, unaffected by the sandbox which spawned them.
>
> WDYT?
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>

Received on Monday, 11 May 2015 14:13:02 UTC