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

On Mon, May 11, 2015 at 4:12 PM, James M. Greene <james.m.greene@gmail.com>
wrote:

> 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").
>

Sure. It's not clear to me that there's a _good_ use of any of these
methods in an iframe, so I'd prefer to just remove the capability entirely,
but if there's a desire to retain the functionality, I'd certainly
implement something like `allow-modals` in Chrome.


> 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.
>

An issue with Flash (and other plugins) is that they generally bypass the
rest of the sandboxing flags. That is, enabling flash while disabling
`window.open` is somewhat ineffectual, as Flash can just pop a new window
with it's native code.

This is somewhat improved in Chrome, as PPAPI allows us a bit more access
to the ways in which Flash can poke at the system, but it doesn't improve
the (terrible) process model, etc. I think it would still be a bit too
dangerous to introduce an `allow-plugins` flag given the sandboxing state
in other browsers, but it's probably a conversation worth having.


> 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.
>

Yes, this is also how I imagined it working. I should have made that clear
in the proposal, but I think (hope!) this naturally falls out of the way
sandbox flags are propagated from frame to frame/window to window.

-mike

--
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:20:11 UTC