Re: Use Cases and Requirements for Saving Files Securely

On Nov 11, 2009, at 3:51 PM, Eric Uhrhane wrote:

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

With the native music player I'm most familiar with, iTunes, the user  
is not even really aware of where audio files are in the file system.  
It does use a directory hierarchy, but it's pretty rare for users to  
actually poke around in there. And the iPod application on iPhone (as  
well as the iPod itself) do not even have a user-visible filesystem  
hierarchy. So overall I don't buy hierarchical directories as a hard  
requirement to build a music player or to expose content to a music  
player.

That being said, I think creating subdirectories in a per-origin  
private use area is probably less risky than user-granted privilege to  
manipulate directories elsewhere in the filesystem. But I would be  
inclined to avoid this mechanism at first, and if it is needed, start  
with the bare minimum. I'm not convinced by your argument that it is  
necessary.

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

The common way this would happen between two native apps would be to  
have an import process of the photo files.

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

That sounds sensible to me as well.

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

Are there usability studies showing any of the apps you mention are  
more usable if they store data in hierarchical directories? I would be  
surprised, because users are increasingly managing large file  
collections with "shoebox" apps that reflect an organization  
completely separate from the filesystem hierarchy. Do you have any  
performance test results to back up the performance claim?


>
>>> 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 Thursday, 12 November 2009 02:59:42 UTC