W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] Iframe Sandbox Attribute - allow-plugins?

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 19 Jan 2012 15:52:09 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1201191548220.16982@ps20323.dreamhostps.com>
On Wed, 13 Jul 2011, John Richards wrote:
> 
> Are there plans to have an 'allow-plugins' value?
> 
> I'm assuming there will be use-cases where the only protection that is 
> desired is prevention of parent redirection.

On Wed, 13 Jul 2011, Adam Barth wrote:
>
> Adding allow-plugins today would defeat the prevention of parent 
> redirection.
> 
> The short answer is we need an API for informing plugins of the sandbox 
> flags and a way of confirming that the plugins understand those bits 
> before we can allow plugins inside sandboxed frames.

Indeed. Even once such an API exists, there would be no need for an 
allow-plugins keyword, since a security-supporting plugin wouldn't need to 
be disabled in the first place.


On Wed, 13 Jul 2011, Julian Reschke wrote:
> 
> ...but that API is outside the scope of what the W3C and the WhatWG 
> currently do, so I think it would be great if defining this flag could 
> be decoupled from progress on the plugin API layers.

On Wed, 13 Jul 2011, Adam Barth wrote:
> 
> It is coupled in the sense that we can't implement the flag unless and 
> until such a plug-in API exists.

On Wed, 13 Jul 2011, Julian Reschke wrote:
> 
> Yes, but we can *define* the flag in HTML and write down what it means with
> respect to plugin APIs.

On Thu, 14 Jul 2011, Anne van Kesteren wrote:
> 
> It seems much better to wait until it can actually be implemented.

On Wed, 13 Jul 2011, Jonas Sicking wrote:
> 
> Especially since it's not at all clear to me that a specific opt-in 
> mechanism is at all needed once we have the appropriate plugin APIs 
> implemented. And those APIs are needed anyway if we want to allow 
> plugins in any form in the sandbox.

Exactly.


On Thu, 14 Jul 2011, Julian Reschke wrote:
> 
> "When the attribute is set, the content is treated as being from a 
> unique origin, forms and scripts are disabled, links are prevented from 
> targeting other browsing contexts, and plugins are disabled."
> 
> A browser negotiating something with plugins using that API and enabling 
> them despite @sandbox would violate the above requirement, no?

On Thu, 14 Jul 2011, Jonas Sicking wrote:
> 
> True. I would be fine with removing the plugin requirement. Or changing 
> it such that it states that plugins can only be loaded if it's done in a 
> manner that ensures that all other requirements are still fulfilled.

I have since done this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 19 January 2012 07:52:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC