Re: Use Cases and Requirements for Saving Files Securely

On Mon, Nov 9, 2009 at 4:21 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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 selection.
> - 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).

I think that exposing audio files to native players would require the
ability to create directories in the native filesystem, thus making
them browsable.  Sure, you could just toss them in a single directory
without hierarchy, but that's not a great user experience, and it hits
serious performance problems with large audio collections.  The same
problems would affect the photo manager.

> - 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.

As stated above, the fourth requirement is needed for audio and
photos.  The second requirement is needed for the photo manager if
it's going to be allowed to manage photos that it didn't download
itself.  How else can it access "My Photos" or wherever I dragged the
photos off my camera?

However, I agree that the second requirement in particular poses large
security risks.  In this email to public-webapps [1] (but not CCed to
DAP--sorry about that) I split up a list of use cases into two groups
based on requirements.  I think we'll make a lot more progress if we
talk about the less-scary group first, which specifically avoids
requirement 2.

I'm not sure that any of my use cases in group 1 really require a
directory API, but they'll perform better and be nicer to use with
one.

>> 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.

      -Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html

Received on Wednesday, 11 November 2009 23:52:56 UTC