Re: text/sandboxed-html

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