- From: Artur Adib <arturadib@gmail.com>
- Date: Thu, 3 Jun 2010 13:26:39 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: public-html@w3.org, Leonard Rosenthol <lrosenth@adobe.com>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>
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 Thursday, 3 June 2010 17:27:15 UTC