- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 18 Jan 2010 10:14:29 -0800
- 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