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

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