Re: Use Cases and Requirements for Saving Files Securely

On Wed, Nov 11, 2009 at 6:59 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

We don't all use iTunes ;'>.

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

I'm OK with that; we can start with a file-writing API and then spec
out directories later.

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

Since these aren't native apps that we're talking about, how do you
picture this importing working?
By "import", do you mean "copy into the web app's storage area"?
That's not necessarily desirable; the user may want to manage the
files in place to save space, or merely because he likes them where
they are.

>> 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 don't have a reference to any study handy; sorry.  But I think I can
make a point here that doesn't require one.  Say your web app is
downloading or creating truly large numbers of files, and you want to
open a small number of them in an external program.  You don't get to
take advantage of the iTunes database/tagging model yet, since you
don't want to import all the files.  All you have is a FileOpen dialog
from your external app or a Windows Explorer or OSX Finder to get you
to the file that you want to grab.  If your web app can't create a
navigable hierarchy, you're stuck sifting through maybe tens of
thousands of files manually.  I accept that that's not the end of the
world; they're probably named something reasonable, and they're in
alphabetical order, but then how do you pull out just the photos from
your Hawaii vacation?  Force the app to use a naming scheme that
builds a hierarchy that way [photos_david_hawaii_06_11_2009_008.jpg]?

As for performance test results, I also have nothing publishable, but
try tossing 100000 mp3 files or photos in a single directory and see
how fast and easy it is to manage on any operating system with the
Finder/Explorer equivalent.  View thumbnails, turn on display of ID3
info...it's not a great experience.

>>>> 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 03:54:58 UTC