Re: text/sandboxed-html

On Thu, Jun 3, 2010 at 12:29 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> My proposal would be not to make any requirements on plugins *unless* we
> have a clear understanding what a plugin is.
>
> With respect to sandboxing, this should be rephrased to define the actual
> restrictions (navigation, scripting, ...), and then have a plugin API
> extension that allows to pass this information down to the plugin.
>

Even if there's no agreed-upon definition of plug-ins, in practice
browsers (such as WebKit) somehow disable those plugins that are
important to us when in a sandboxed iframe (Flash videos, etc).

Thus, it seems to me like some browsers already have a working
definition of the "sandboxed plugins browsing context" (SPBC) flag
(http://www.whatwg.org/specs/web-apps/current-work/#sandboxed-plugins-browsing-context-flag),
even if there's no unambiguous definition of "plugin".

So, can't we break up the problem into two *independent* parts?

1) Everything you are concerned with (standardize the definition of
what a plug-in is, have APIs pass down sandbox info down to plug-ins,
etc).

2) Introduce the "allow-plugins" white-list option, which turns on/off
the SPBC flag already implemented in some browsers.

I would think that it's possible for both #1 and #2 to make progress
in parallel, and not necessarily serially (#1 first, #2 later).  That
would certainly mitigate our problem.

Again, if the developer isn't happy with the "allow-plugins" option,
they can simply not use it.