- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 10 Jun 2010 14:21:52 -0700
- 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 UTC