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

Re: text/sandboxed-html

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 4 Jun 2010 09:37:53 +1200
Message-ID: <AANLkTin5P3X2Kk2wDiR91TWXVgWsGFQpRl6GL4xLOM2h@mail.gmail.com>
To: Artur Adib <arturadib@gmail.com>
Cc: public-html@w3.org, Leonard Rosenthol <lrosenth@adobe.com>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>
On Fri, Jun 4, 2010 at 3:55 AM, Artur Adib <arturadib@gmail.com> wrote:

> 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.


Could an attacker use a custom Flash object to force top-level navigation?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Received on Thursday, 3 June 2010 21:38:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:18 UTC