Re: [widget] Security model

(again with my "editor" hat on)

On 5/19/09 12:07 PM, Thomas Roessler wrote:
> 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.
>

I don't know what "I don't need anything scary" is.

> 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.

Right. I intended this too. The domain in my model is "widget://". 
Referer: is disabled.

> 2. Communication of that domain of trust with the network is prohibited
> by default, but can be turned on selectively.

I think the inverse should apply within the rules of the application 
type that is the start file (i.e., if start file is HTML, then HTML 
rules apply, if start file is Flash, flash rules apply, and so on). Who 
are we to impose rules on those formats?

> 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 ...).

I disagree. It should be up to the application type of the start file 
what it allows.

> 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.

Agreed.

> 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.

Agreed.

> 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/".

Right, like "widget://" or "widget://[uuid]"

> 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).

Agreed.

> The disagreement was whether the iframe from "http://foo.com/" should be
> able to access network resources that do not "match" "http://foo.com/".

In my model, yes. I think it's futile to fight the Web security model. 
Authors will expect consistent behavior.

> My argument was that I'd prefer to not specify yet another subset of the
> HTML5 security model.

I agree.

> 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.

Can the following two documents communicate when run locally from my 
hard drive?

<html>
<iframe src="http://google.com"/>
</html?

Received on Tuesday, 19 May 2009 10:37:20 UTC