- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 10 Jun 2010 18:56:11 -0700
- To: Artur Adib <arturadib@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, robert@ocallahan.org, public-html@w3.org, Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>
On Thu, Jun 10, 2010 at 6:51 PM, Artur Adib <arturadib@gmail.com> wrote: > What do you mean by "change the semantics"? Authors don't need to > worry about modifying their code, as the syntax "allow-plugins" won't > (or shouldn't) change after the plugin API understands sandbox. The > changes are all under the hood, and all for the better (i.e. better > security). Right, that's the problem with that approach. When users try to upgrade from Browser Version N to Browser Version N+1, sites that rely on the old behavior of allow-plugins will break. That means users will prefer Browser Version N, which means browser vendors will never create Browser Version N+1, and we'll be stuck with the insecure version forever. > (I was making a wild optimistic guess when I said "<1 year"; I am not > in the plugin API development business.) The longer it takes, the more calcified the web will become around the insecure behavior. Adam > On Thu, Jun 10, 2010 at 9:25 PM, Adam Barth <w3c@adambarth.com> wrote: >> Realistically, it's a tricky business to change the semantics of a >> piece of the web platform after it's used by developers. If we're >> only talking about a year, maybe we should just be patient. >> >> Adam >> >> >> On Thu, Jun 10, 2010 at 6:18 PM, Artur Adib <arturadib@gmail.com> wrote: >>> How about this transition story: >>> >>> (1) Introduce "allow-plugins", allowing *any* plugin regardless of >>> sandbox compliance; add warning to the HTML5 specs along the lines of >>> "WARNING: This white-list option might allow some plugins to break >>> sandbox restrictions, etc."; >>> (2) Wait until one or two major plugins comply with sandbox; >>> (3) Modify (1) so that only compliant plugins are allowed by >>> "allow-plugins"; remove warning from HTML5 specs. >>> >>> Ideally, (2) would happen ASAP (<1 year?), so that the web wouldn't >>> have time to discover and exploit plugin-sandbox vulnerabilities. >>> >>> If it takes too long to happen, authors can just stop using the option. >>> >>> -Artur >>> >>> >>> >>> On Thu, Jun 10, 2010 at 7:33 PM, Maciej Stachowiak <mjs@apple.com> wrote: >>>> >>>> On Jun 10, 2010, at 2:24 PM, Robert O'Callahan wrote: >>>> >>>> On Thu, Jun 10, 2010 at 5:21 PM, Adam Barth <w3c@adambarth.com> wrote: >>>>> >>>>> 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? >>>> >>>> Users that don't have XYZ random plugin installed (i.e. almost all users) >>>> would be protected. >>>> >>>> Unless XYZ random plugin is "the old version of some very popular plugin". >>>> I'm reasonably confident that at least Flash, Java and Silverlight are >>>> general-purpose enough to allow circumvention of any of the sandboxed iframe >>>> defenses, and I'm not confident enough in users having the latest versions >>>> of those to consider that a strong security measure. >>>> In the long run, I think it makes a lot more sense to have a feature that >>>> only allow plugins that respect sandboxing restrictiions. If we want a >>>> shorter-term feature to allow plugins, then it would be good to have a clear >>>> transition story. >>>> Regards, >>>> Maciej >>>> >>> >> >
Received on Friday, 11 June 2010 01:57:03 UTC