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

Re: [widget] Security model

From: Robin Berjon <robin@berjon.com>
Date: Tue, 19 May 2009 12:36:48 +0200
Cc: marcosc@opera.com, public-webapps <public-webapps@w3.org>
Message-Id: <7F11261F-E13F-4E8B-AB8A-E8A9EB3E6332@berjon.com>
To: Thomas Roessler <tlr@w3.org>
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 ;-)

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.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Tuesday, 19 May 2009 10:37:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT