- From: Artur Adib <arturadib@gmail.com>
- Date: Thu, 3 Jun 2010 11:55:21 -0400
- To: public-html@w3.org
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>
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