Re: text/sandboxed-html

>
> In which case we probably could get away with just defining new 
> constants for NPPVariable.
> '


maybe so for a 'tusted'plugin, but isn't this the host responsibility?
A plugin can claim anything it wants.
The host determines whether it can tie into the host DOM.
The author, host browser, and user prefs make the environment and the 
the plugin is limited. It would help the plugin to be able to find out 
what environment it has access to.

Thanks and Best Regareds,
Joe

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Leonard Rosenthol" <lrosenth@adobe.com>; "Adam Barth" 
<w3c@adambarth.com>; "Ian Hickson" <ian@hixie.ch>; 
<public-html@w3.org>
Sent: Tuesday, January 19, 2010 6:24 AM
Subject: Re: text/sandboxed-html


> 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.
>
> Best regards, Julian
>

Received on Tuesday, 19 January 2010 17:23:43 UTC