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:14:47 +0200
Cc: 'Peter-Paul Koch' <pp.koch@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <B0653CC0-C1D9-4FE2-8FBA-8378692AEA92@robineko.com>
To: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>
Hi Claes,

On Oct 20, 2009, at 16:26 , Nilsson, Claes1 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.

I think that the issue here is that we cannot design APIs around these  
assumptions. If an API is intended to be 100% specific to widgets,  
then its place is in TWI: http://www.w3.org/TR/widgets-apis/ or  
another API created by the WebApps WG.

DAP APIs are intended to be generic, and usable in an open Web context.

I am concerned (again) that this discussion has veered off track with  
security considerations way too early. Most of the APIs we're looking  
at are potentially dangerous  that's why this WG has a policy side as  
well. Frankly, Mr Evil can steal my Facebook password as much as he  
wants; I'll be a whole lot more pissed off if he can write to my file  
system (which is what this issue is about in the first place).

So back to functionality, can we see some code of what you would  
expect this API to look like? Maybe a little WebIDL snippet? And a few  
comments explaining what goes on, how it differs from storing  
credentials in localStorage, etc.?

Robin Berjon
   robineko  hired gun, higher standards
Received on Friday, 23 October 2009 13:15:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:12 UTC