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

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 Sunday, 24 January 2010 23:04:08 UTC