Re: What defines a "plugin"? WRT sandboxing?

On Jan 24, 2010, at 8:45 PM, Adam Barth wrote:

> The problem with that approach is that authors will have a difficult
> time predicting how user agents will behave.  Perhaps a more
> operational definition is in order?  We could say that sandboxed
> content will not be able to use the <object> or <embed> elements
> (including the implied versions that can be created via frames).

You would also want to banish <applent> in that case. Are we ok with sandboxed content embedding unusual things via <img>, <video> or <audio> if the browser supports that? Safari supports PDF in the <img> element, and also as a CSS background image.

 - Maciej

> 
> Adam
> 
> 
> On Sun, Jan 24, 2010 at 11:03 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> BUT a browser/UA is allowed to instantiate AY content that it believes complies with the provided security model, correct?
>> 
>> So Safari, if it believes that their built-in PDF support is "sandbox safe" could display such document on the Mac even though on Windows the same browser would not do so.   OR for that matter, what about a UA which relies on a plugin for SVG?  Are they to not allow embedded SVG in a sandbox simply because they have to use a plugin to implement it?
>> 
>> My point isn't to try to avoid the sandbox - I fully support the idea.  HOWEVER, I believe that "plugins" are being singled out inappropriately and that the correct solution is a more well thought out definition of what exactly we are trying to achieve.
>> 
>> Leonard
>> 
>> 
>> -----Original Message-----
>> From: Adam Barth [mailto:w3c@adambarth.com]
>> Sent: Sunday, January 24, 2010 10:56 PM
>> To: Leonard Rosenthol
>> Cc: Maciej Stachowiak; public-html@w3.org
>> Subject: Re: What defines a "plugin"? WRT sandboxing?
>> 
>> The fact remains that we cannot permit sandboxed content to
>> instantiate plugins that do not understand the sandbox security model.
>>  If we allowed that, then the sandboxed content could use those
>> plugins to circumvent the sandbox, rendering the feature useless.
>> 
>> Adam
>> 
>> 
>> On Sun, Jan 24, 2010 at 6:12 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>> If I understand what you are saying, then it also means that your internal
>>> support for ANY format - whether it be specifically listed in the HTML5 spec
>>> or not AND whether it is implemented via plugin or not - would need to be
>>> covered by the sandbox rules.   That seems completely valid and logical (and
>>> consistent).
>>> 
>>> 
>>> 
>>> In that case, I would argue that plugins NOT EVEN BE MENTIONED in the
>>> sandbox specification - and that instead, the general rules for sandboxing
>>> (scripting, external refs, etc.) be applied to the content regardless of how
>>> that content is displayed.
>>> 
>>> 
>>> 
>>> So in Safari's case, if someone references QuickTime and they are allowing
>>> external references, then it would be OK for you to use it.  OR if your PDF
>>> viewer DID support scripting AND the sandbox rule was allow scripting, then
>>> it would be OK for you to view it, otherwise it would not.
>>> 
>>> 
>>> 
>>> The rule for plugins then simply become whether the UA can establish whether
>>> the plugin is able to adhere to the requirement(s) for that sandbox. If it
>>> can, then it runs - if it cannot, then it can't.  BUT explicit disabling of
>>> plugins should not be an option!
>>> 
>>> 
>>> 
>>> Leonard
>>> 
>>> 
>>> 
>>> From: Maciej Stachowiak [mailto:mjs@apple.com]
>>> Sent: Sunday, January 24, 2010 6:03 PM
>>> To: Leonard Rosenthol
>>> Cc: public-html@w3.org
>>> Subject: Re: What defines a "plugin"? WRT sandboxing?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Jan 24, 2010, at 5:44 AM, Leonard Rosenthol wrote:
>>> 
>>> When defining and implementing sandboxing, is the requirement to disable
>>> plugins restricted ONLY to actual technologies implemented by plugins to the
>>> browser/UA _OR_ does it really mean content not in a format documented by
>>> the HTML5 spec.
>>> 
>>> 
>>> 
>>> For example, Safari (on the Mac) knows how to natively view PDF documents.
>>> If Safari encounters an HTML document with a reference to an embedded PDF
>>> (<object> or <embed>) it will currently render that document through its own
>>> technology, whereas other browsers will use available plugins to do so.
>>> When that same HTML is now served as sandbox, then clearly the other
>>> browsers will stop viewing PDF - but should Safari?
>>> 
>>> 
>>> 
>>> OR consider Adobe AIR which (through WebKit) can act as an HTML5 UA and
>>> incorporates native support for Flash.  Does it have to disable Flash, since
>>> it isn't using sandbox?
>>> 
>>> 
>>> 
>>> For data types where Safari has built-in support, we'd likely turn off any
>>> that are able to do scripting or that may fetch additional resources over
>>> the network, unless we know how to apply the sandbox rules to that content.
>>> So PDF would be ok, because our built-in PDF doesn't do scripting. As would
>>> our built-in audio and video support via media elements. We would allow SVG
>>> and HTML because it's straightforward to make them follow the sandbox rules.
>>> But we would not allow Java (which is actually implemented partly as a
>>> plugin and partly via built-in code, but that's not super relevant). It runs
>>> code, and that's sort of intrinsic to its function. We would now allow the
>>> QuickTime plugin, even if it were built-in, because it fetches remote
>>> resources.
>>> 
>>> 
>>> 
>>> I think the bottom line is for any given piece of code, can you verify that
>>> it enforces the sandbox constraints?
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Maciej
>>> 
>>> 
>>

Received on Monday, 25 January 2010 04:50:11 UTC