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

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

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Sun, 1 Nov 2009 15:00:12 -0500
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, "'Paddy Byers'" <paddy.byers@gmail.com>, Peter-Paul Koch <pp.koch@gmail.com>, Robin Berjon <robin@robineko.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <E55F8921-9B6E-465E-9F86-015D15CF8CE8@nokia.com>
To: ext Marcin Hanclik <Marcin.Hanclik@access-company.com>
aren't these two requirements different and shouldn't we have both?

regards, Frederick

Frederick Hirsch
Nokia



On Oct 21, 2009, at 8:16 AM, ext Marcin Hanclik wrote:

> Hi,
>
> I think it is important to distinguish between protecting APIs and  
> protecting data.
> At present we focus mainly on protection of the APIs.
> What about the case that the filesystem API is enabled for everyone,  
> but the rights are related to some paths in the filesystem?
> If we just concentrate on protecting APIs, we would probably need to  
> define new APIs for the secure storage case.
> So I would rephrase:
> "SHOULD provide secure storage and management of secret information,  
> e.g. server login credentials or API keys.”
> to
> "SHOULD provide means to protect or restrict access to the parts of  
> a given file system based on some security model, possibly different  
> from the API security model”.
> (depending on what we will be able to agree on in the future).
>
> This is the area that has been disputed in BONDI for a long time and  
> there is currently no standardized end-2-end (from developer to  
> policy writer) solution to that.
> It is in general the area where the APIs meet security, the coupling  
> is quite tight, although may not be so visible at first sight.
>
> Thanks,
> Marcin
>
> Marcin Hanclik
> ACCESS Systems Germany GmbH
> Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
> Mobile: +49-163-8290-646
> E-Mail: marcin.hanclik@access-company.com
> From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org 
> ] On Behalf Of Nilsson, Claes1
> Sent: Wednesday, October 21, 2009 1:58 PM
> To: 'Paddy Byers'; Peter-Paul Koch; Frederick Hirsch
> Cc: Robin Berjon; public-device-apis@w3.org
> Subject: RE: ISSUE-11: Gathering requirements [FileSystem API]
>
> I fully agree with Paddy. This is a general discussion that applies  
> to all sensitive JavaScript APIs that we need to protect from  
> unauthorized access.
>
> However, the issue remains whether we should add a requirement to  
> the FileSystem API. I suggest:
>
> "SHOULD provide secure storage and management of secret information,  
> e.g. server login credentials or API keys.”
>
> Best regards
>   Claes
>
>
>
> From: Paddy Byers [mailto:paddy.byers@gmail.com]
> Sent: onsdag den 21 oktober 2009 11:36
> To: Peter-Paul Koch; Frederick Hirsch
> Cc: Nilsson, Claes1; Robin Berjon; public-device-apis@w3.org
> Subject: Re: ISSUE-11: Gathering requirements [FileSystem API]
>
> Hi,
>
> > 1) Signing gives:
>
> ...
>
> I think this discussion is common to all APIs and belongs to a new  
> issue which should be raised. This issue should be confined to the  
> filesystem API discussion.
>
> I suggest raising a new issue: widget signing and trust models.
>
> Thanks - Paddy
>
>
> ________________________________________
>
> Access Systems Germany GmbH
> Essener Strasse 5 | D-46047 Oberhausen
> HRB 13548 Amtsgericht Duisburg
> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>
> www.access-company.com
>
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain information that  
> is privileged or confidential, and is intended for use only by the
> individual or entity to which it is addressed. Any disclosure,  
> copying or distribution of the information by anyone else is  
> strictly prohibited.
> If you have received this document in error, please notify us  
> promptly by responding to this e-mail. Thank you.
Received on Monday, 2 November 2009 01:27:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT