Re: [widget] Security model

On 5/19/09 12:36 PM, Robin Berjon wrote:
> On May 19, 2009, at 12:07 , Thomas Roessler wrote:
>> My take on where we were in the end of the call yesterday is as follows:
>>
>> 1. A widget runs in its own domain of trust.
>>
>> 2. Communication of that domain of trust with the network is
>> prohibited by default, but can be turned on selectively.
>>
>> 3. If the permission is turned on selectively, then it becomes
>> possible to have something like an iframe from an origin on the Web
>> involved (or a script tag, or ...).
>>
>> 4. If such an iframe occurs, then the HTML5 security model applies for
>> communication between the different trust domains, with a random
>> origin applying to the widget.
>>
>> 5. If such an iframe occurs, it won't have access to device APIs under
>> the model that the widgets 1.0 spec includes. It might acquire that
>> access later on, e.g. as a result of the device API working group.
>>
>> (...)
>>
>> The disagreement was whether the iframe from "http://foo.com/" should
>> be able to access network resources that do not "match"
>> "http://foo.com/". My argument was that I'd prefer to not specify yet
>> another subset of the HTML5 security model.
>
> Vodafone supports this model. We would rather that content referenced as
> web content worked as such, i.e. had the web/HTML5 security model
> applied to it. We do not find that the attack surface is unacceptably
> increased, and furthermore trying to fix that is akin to trying to fix
> the web's security model, which might sound nice in theory but is laden
> with issues in practice. In other words, we think that Arve's proposal
> breaks the web ;-)

Arve's proposal cannot break the web when the Web does not consider 
widgets part of it.

> Given this, we believe that it is both possible and necessary to specify
> <access> within the bounds of the P+C LC. We keep the current definition
> of <access>, specify it to apply only to the contents of the widget, and
> defer to the specifications defining the content for everything else.
>

Aside from parsing the element, the <access> element makes no sense in 
the context P&C spec.

Received on Tuesday, 19 May 2009 11:57:30 UTC