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

On Jan 24, 2010, at 10:12 AM, Leonard Rosenthol 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.

If that was the design, we'd probably never allow any plugins. Mixing a different execution model, even if the author has chosen to allow script, is something that can have unpredictable security consequences, so we would not do it without specific opt-in. So you're not going to see allow-script enabling Java for example, and it certainly wouldn't make sense to run any plugin that runs some form of code when allow-script is not set.

>  
> 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!

The option should be to explicitly enable them back, after being disabled by sandbox. And then only if they can follow the rules. The use cases for this require predictable attack surface and strong guarantees of what can and can't be done more than they require availability of a wide range of features.

Regards,
Maciej