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

Re: Use Cases and Requirements for Saving Files Securely

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 09 Nov 2009 16:21:06 -0800
Cc: Doug Schepers <schepers@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, public-device-apis@w3.org
Message-id: <D2CE01DF-E3A6-4430-9D76-80B47031C07F@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Nov 9, 2009, at 12:08 PM, Ian Hickson wrote:

> On Mon, 2 Nov 2009, Doug Schepers wrote:
>> Please send in use cases, requirements, concerns, and concrete
>> suggestions about the general topic (regardless of your opinion  
>> about my
>> suggestion).
> Some use cases:
> * Ability to manage attachments in Web-based mail clients, both  
> receiving
>  and sending
> * Ability to write a Web-based mail client that uses mbox files or the
>  Maildir format locally
> * Ability to write a Web-based photo management application that  
> handles
>  the user's photos on the user's computer
> * Ability to expose audio files to native media players
> * Ability to write a Web-based media player that indexes the user's  
> media

These are good use cases.

> Basically these require:
> - A per-origin filesystem (ideally exposed as a directory on the  
> user's
>  actual filesystem)
> - The ability to grant read and/or write privileges to a particular
>  directory to an origin
> - An API for files that supports reading and writing arbitrary ranges
> - An API for directories that supports creating, renaming, moving, and
>  enumerating child directories and files

Can you explain how these requirements follow from the use cases? It  
seems to me the use cases you cited would be adequately covered by:

- Existing facilities including <input type="file"> with multiple  
- File read facilities as outlined in the File API spec.
- Ability to create named writable files in a per-origin private use  
area (with no specific requirement that they be browsable by the user,  
or in hierarchical directories).
- Ability to write to a user-selected file (perhaps using something  
like <input type="save">).

In particular I don't see how the second or fourth requirements follow  
from your use cases, and they seem to impose a great deal of security  
risk. I would not want to ship a Web-facing API that gives the ability  
to ask for read/write access to the user's full home directory. That  
seems like a security decision that the user does not have the  
information to make. Writing to files in a private use area, and one- 
time reading or writing files selected by the user (perhaps many at a  
time), seem much less risky.

> I'd be happy to volunteer to edit the Directory component of this,  
> working
> in tandem with Arun's draft for file access.

I don't see how manipulation of directories is required for any of the  
use cases you cited.

Received on Tuesday, 10 November 2009 00:21:51 UTC

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