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

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

From: Brian LeRoux <brian.leroux@westcoastlogic.com>
Date: Tue, 6 Oct 2009 10:50:30 -0700
Message-ID: <a4bcf6320910061050h5c62bdfxa86fbaf18ede115a@mail.gmail.com>
To: richard.tibbett@orange-ftgroup.com
Cc: pp.koch@gmail.com, Claes1.Nilsson@sonyericsson.com, public-device-apis@w3.org
Security is a tricky beast to address but I feel it is worth exploring
if we want the web to be a first class development platform.

Certainly the current analogue would be the sqlite storage which has
no security restrictions but choosing to not solve access control and
security isn't solving anything at all. And saying a language is
inherently insecure could be applied to *any* software language or
platform.

The iPhone SDK gives us the follow abstractions:

 isReadableFileAtPath:
 isWritableFileAtPath:
 isExecutableFileAtPath:
 isDeletableFileAtPath:

Sorta nice wrappers around the lower level permissions. A file can
only be read/write to a memory space dedicated to the that
application. Android allows for anything in java.io in a similar data
directory (which is separate from the app directory/package).

Perhaps something similar could be proposed?


On Tue, Oct 6, 2009 at 9:39 AM,  <richard.tibbett@orange-ftgroup.com> wrote:
> On Oct 6, 2009, at 16:52 , richard.tibbett@orange-ftgroup.com wrote:
>>
>> Mostly it puts the end-user at the mercy of the developer's
>> competency in keeping their credentials secure and I don't
>> trust all JS developers (most of them like you guys of course ;-D).
>>
>
> (*I trust* most of them, like you guys, of course ;-D)
>
> I just wanted to clarify that line as it came over badly on re-reading!
> :-O
>
> Rich
>
>
Received on Tuesday, 6 October 2009 18:07:04 UTC

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