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

Re: text/sandboxed-html

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 10 Jun 2010 14:21:52 -0700
Message-ID: <AANLkTik93utRE1qvRsHMbohhFctHBF3pHa2Cy5Kc0As1@mail.gmail.com>
To: Artur Adib <arturadib@gmail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, public-html@w3.org, Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>
I guess I don't understand the transition plan.  Would we eventually
remove support for plug-ins that don't understand sandboxing?  If not,
couldn't an attacker always use XYZ random plug-in to break the
security properties?

Adam


On Thu, Jun 10, 2010 at 12:29 PM, Artur Adib <arturadib@gmail.com> wrote:
> To answer your question: Less likely to work for now, strictly prevent
> it when the plugin APIs respect @sandbox.
>
> As I have been emphasizing, it's a matter of changing the order of
> implementation: introduce "allow-plugins" first, regardless of the
> status of plugin @sandbox compliance.  (Of course, users should be
> alerted to the risks of "allow-plugins").
>
> The order of course won't matter in the long run, after both are
> implemented, but it will be *very* useful in practice until then.
>
> If the order is the other way around, I'm afraid @sandbox might be
> rarely used until the entire package (plugin API compliance, browser
> updates, etc) is finished.  (e.g.: our app can't use it until it
> supports plugins).
>
> -A.
>
>
>
> On Thu, Jun 10, 2010 at 3:05 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> Are you looking to strictly prevent top-level navigation, or just to make
>> sites' existing top-level navigation less likely to work?
>
Received on Thursday, 10 June 2010 21:22:48 GMT

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