W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ISSUE-11: Gathering requirements [FileSystem API]

From: Robin Berjon <robin@robineko.com>
Date: Fri, 23 Oct 2009 15:04:59 +0200
Cc: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <5785EC3D-315C-4785-85A6-49A132E0616C@robineko.com>
To: Peter-Paul Koch <pp.koch@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC