- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 03 Jun 2010 19:31:07 +0200
- 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 UTC