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