W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widget] Security model

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 19 May 2009 13:56:48 +0200
Message-ID: <4A129E80.4050701@opera.com>
To: Robin Berjon <robin@berjon.com>
CC: Thomas Roessler <tlr@w3.org>, public-webapps <public-webapps@w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC