W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: text/sandboxed-html

From: Artur Adib <arturadib@gmail.com>
Date: Thu, 3 Jun 2010 13:26:39 -0400
Message-ID: <AANLkTiljaopEdieman_1kjEly-ySv6vuqYuBqk0KNQQ1@mail.gmail.com>
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
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,

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC