Re: [widget] Security model

I'm not particularly happy with this proposal, mostly since it doesn't  
seem to make the case of "I don't need anything scary" easy.

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.

Example:  <access> permits access to the domain foo.com.  A widget's  
main HTML includes something like:
    <iframe src="http://foo.com/"/>

We now have a document object that describes the top-level widget, and  
a document object that describes the iframe.  The top-level widget  
document object will have a random origin that is distinct from "http://foo.com/ 
".  That means that the two objects can't script each other, and can  
only exchange data through postMessage (leaving side channels out of  
the picture for the moment).

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.  Arve's argument was that attack  
surface would grow unacceptably, and that, therefore, a Web  
application that executes within an iframe that can in any way  
communicate with a widget MUST be constrained in the same way the  
widget is.

Arve, I hope this is a fair summary.  Maybe we can start the  
conversation by reflecting whether any of these points of agreement  
aren't?
--
Thomas Roessler, W3C  <tlr@w3.org>




On 19 May 2009, at 11:18, Marcos Caceres wrote:

> With my "editor" hat on, I would like to propose the following
> security model for widgets:
>
> 1. If no <access> element is used, the application type (e.g., HTML,
> Flash, whatever) is responsible for providing the security
> context/rules under which the widget runs. For HTML this means that a
> widget runs as if you had dragged a HTML file from your hard-drive
> into the Web browser.
>
> Then, it is up to the implementers if they allow such widgets to run
> or have access to features (APIs). Distributors may not allow these
> widgets to be distributed, but that is their prerogative.
>
> This defers the security problem to HTML5 or whoever wants to make use
> of widgets as a packaging format.  HTML5 already has to deal with
> situation where HTML files are run locally or with a synthetic origin
> (think email attachments).
>
> 2. If <access> is used, then this is an "op-in" to a "widget security
> model" and all network activity is blocked by all means (like a
> firewall), except those access requests made via <access> element that
> have been granted by the UA. Access requests are granted via the UA
> security policy, which is outside the scope of the Widgets spec.
>
> I personally think <access> should be removed from Widgets 1.0 and
> deferred to Widgets 2.0 once it is properly sorted out.
>
> -- 
> Marcos Caceres
> http://datadriven.com.au
>

Received on Tuesday, 19 May 2009 10:07:19 UTC