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.

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC