W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: text/sandboxed-html

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 18 Jan 2010 10:14:29 -0800
Message-ID: <7789133a1001181014h6daa244bi3dc81e30c6c3bff1@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Maciej Stachowiak <mjs@apple.com>, Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
On Mon, Jan 18, 2010 at 10:04 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Maciej Stachowiak wrote:
>> ...
>> I would be hesitant to add a feature to HTML5 that can't actually be
>> implemented (and will be a potentially confusing no-op) until another
>> standards group does some design work. It's not even clear at this time if
>> this is a feature authors will really want with sandboxed iframes.
>> ...
> Before we head over to plugin-futures it would be nice if we could write
> down what the requirements are...:
> - a plugin needs to be able to signal support for the "sandbox" mode (is on
> initialization sufficient?)
> - when the plugin instance is created, the various sandbox related flags
> defined in <http://dev.w3.org/html5/spec/Overview.html#the-iframe-element>
> need to be passed to the plugin
> - the plugin needs to apply the constraints defined by these flags to the
> content it displays
> Q: does the set of flags need to be extensible?

We might want to support something like Content-Security-Policies in
the future, so an extensible set of flags seems like a good idea.  I'm
not sure we should design the API on this list, but you could imagine
wanting to know which flags the plug-in supports instead of just
having a single "supports sandboxing" bit.

Received on Monday, 18 January 2010 18:15:21 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:07 UTC