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

Re: text/sandboxed-html

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 19 Jan 2010 12:59:12 -0800
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
Message-id: <F67A5037-BC36-4608-A048-C9AB2A961B38@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Jan 19, 2010, at 6:24 AM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> On Jan 18, 2010, at 10:04 AM, Julian Reschke 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?)
>> I don't remember everything about how the plugin API works offhand, but ideally it should be possible to determine this before the plugin is instantiated. One possibility is to have a second init function that takes sandbox flags - having a non-NULL value for this function would indicate sandbox support. Or perhaps there is a more explicit way.
> 
> It appears that allowing this before initialization may be tricky; if I recall correctly, the mechanism for finding the supported mime types currently is platform-dependent; and it's probably better not to add to that.
> 
> Would there be a problem with instantiating the plugin, and checking with NP_GetValue for Sandboxing support?
> 
>>> - 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
>> In theory the plugin could get this through the DOM but it does seem better to pass the flags explicitly.
>>> - 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?
>> I think it would be wise to allow for future changes in the set of flags, after all, we are discussing the possibility of adding a flag even now. I wonder if this means that the plugin needs to indicate which flags it understands? Perhaps as long as all new flags only remove restrictions instead of adding them, it's ok if a plugin doesn't understand a new flag.
> 
> In which case we probably could get away with just defining new constants for NPPVariable.

I think we might be getting into the level of detail that's better discussed on plugin-futures now.

Regards,
Maciej
Received on Tuesday, 19 January 2010 20:59:50 UTC

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