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

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

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 25 Jan 2010 04:45:55 +0000
Message-ID: <7789133a1001242045m2378a6f9h451e1ec9894bacbb@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
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).

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:46:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT