W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: text/sandboxed-html

From: Artur Adib <arturadib@gmail.com>
Date: Thu, 3 Jun 2010 11:55:21 -0400
Message-ID: <AANLkTinr7JOEHa8lGvrTdY646qmdLwgJYFlVp2hT6TSv@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:09 GMT