- From: Robin Berjon <robin@robineko.com>
- Date: Fri, 23 Oct 2009 15:04:59 +0200
- To: Peter-Paul Koch <pp.koch@gmail.com>
- Cc: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
On Oct 21, 2009, at 11:30 , Peter-Paul Koch wrote: >> 2) The scenarios you describe will not be possible if we assume >> that only digitally signed web applications, e.g. Web Widgets >> signed according to http://www.w3.org/TR/widgets-digsig/, are >> allowed to access the proposed "secure data storage" API. A >> widget's content can of course be copied and altered but access to >> the "secure data storage" API will in this case be denied by the >> device's widget runtime as the signature will be invalid. > > This I don't quite understand. I see the basic point, but wonder what > happens in the case of externally downloaded scripts. > > If a widget downloads an external script from the Internet, will the > signing become invalid? It shouldn't, because there are use cases for > downloading external scripts. > > On the other hand, as I said before an externally downloaded script > can become a danger. In a widget context, the ability to download an external script is controlled by WARP: """ For instance, in HTML 5 [HTML5] a script loaded off the network into a document running in the widget execution scope is itself in the same scope, whereas a document loaded off the network in an iframe will be in the web execution scope. """ -- http://www.w3.org/TR/widgets-access/#policy That means that you can't load arbitrary scripts into a context that has privileged access to those APIs: you can only load those that reside on websites that have been listed as okay using <access> elements in config.xml (which can be signed). But note however that this does indeed increase the attack surface since the scripts that are loaded from <access>-enabled sources are not signed. Compromising the remote server, or screwing around with the DNS can compromise the widget execution context. (Note that updates don't have this issue since they can be signed). I'd like to point out however that I'm not certain that restricting this discussion to the widget context is productive. The APIs we define are intended for the entirety of the Web, and need to have a way of working from within a vanilla web page (provided the user grants access one way or another), all of that without signing, without widgets, without WARP. -- Robin Berjon robineko — hired gun, higher standards http://robineko.com/
Received on Friday, 23 October 2009 13:05:32 UTC