Re: text/sandboxed-html

On Jun 3, 2010, at 8:55 AM, Artur Adib wrote:

> Maciej Stachowiak wrote:
> 
>> I would be hesitant to add a feature to HTML5 that can't actually be
>> implemented (and will be a potentially confusing no-op) until another
>> standards group does some design work. It's not even clear at this
>> time if this is a feature authors will really want with sandboxed
>> iframes.
> 
> 
> I wanted to revive this discussion, as I seem to be precisely such an author.
> 
> We're developing an app that shows arbitrary 3rd-party content through
> iframes.  We're primarily interested in @sandbox to forbid top-level
> navigation;  everything else, from scripts to forms and plugins, we're
> OK with.
> 
> So the only missing option for us is "allow-plugins".  (Right now, our
> users can't see embedded plugin videos from such sandboxed sites,
> which is a major setback for us).
> 
> In our experience with tons of external sites, most top-level
> navigation is done by Javascript code, and not by plugins.  So even if
> the plugin APIs are not yet fully compatible with a sandboxed
> environment, having the "allow-plugins" option would be extremely
> helpful to us.
> 
> Is there a major drawback in offering this white-list option?  It
> seems to me that, provided developers are warned about the inherent
> dangers of allowing plugins in the HTML5 specs, there's no harm in
> adding this option;  if you're not willing to take the risk, simply
> don't use it.
> 
> Any thoughts?

If allow-plugins is implemented in a simpleminded way, then it will be very easy to use plugins to circumvent the restriction on top-level navigation. Are you looking to strictly prevent top-level navigation, or just to make sites' existing top-level navigation less likely to work?

Regards,
Maciej

Received on Thursday, 10 June 2010 19:05:49 UTC