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

Re: text/sandboxed-html

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 03 Jun 2010 19:31:07 +0200
Message-ID: <4C07E6DB.8040005@gmx.de>
To: Artur Adib <arturadib@gmail.com>
CC: public-html@w3.org, Leonard Rosenthol <lrosenth@adobe.com>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>
On 03.06.2010 19:26, Artur Adib wrote:
> 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.

I agree that both can and should be discussed separately.

Sam is going to say: raise a bug. :-)

Best regards, Julian
Received on Thursday, 3 June 2010 17:31:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:09 GMT