W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2015

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

From: Mike West <mkwst@google.com>
Date: Mon, 11 May 2015 16:19:24 +0200
Message-ID: <CAKXHy=c=G52pBLZ6Nx=ce8KGveMa0PRwmcQw9VP61Jzch=DAcA@mail.gmail.com>
To: "James M. Greene" <james.m.greene@gmail.com>
Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>, Chris Coyier <chriscoyier@gmail.com>, David Bruant <bruant.d@gmail.com>, Ian Hickson <ian@hixie.ch>, Alex Russell <slightlyoff@google.com>
On Mon, May 11, 2015 at 4:12 PM, James M. Greene <james.m.greene@gmail.com>

> 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 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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 11 May 2015 14:20:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:31 UTC