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.
