RE: text/sandboxed-html

Actually, we have a definition in the current draft (<http://dev.w3.org/html5/spec/infrastructure.html#plugins>) which is based on discussions from this list.  It's a good definition and I, for one, am happy with it.

However, I find NO REFERENCE in the W3C HTML5 document to any "sandboxed plugins browsing context".  Can you please tell me where this is in the official standard?  If it is not present there, than it clearly is not a part of the standard but is a browser-centric extension that we shouldn't be basing any designs around.

As for your suggestion of an "allow-plugins" option, seems good to me!

Leonard

-----Original Message-----
From: Artur Adib [mailto:arturadib@gmail.com] 
Sent: Thursday, June 03, 2010 10:27 AM
To: julian.reschke@gmx.de
Cc: public-html@w3.org; Leonard Rosenthol; Adam Barth; Ian Hickson
Subject: 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.

Received on Friday, 4 June 2010 04:03:24 UTC