Re: text/sandboxed-html

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?

-Artur

Received on Thursday, 3 June 2010 15:55:58 UTC