Re: Use Cases and Requirements for Saving Files Securely

This is really getting into fantasy-land... Writing a file and hoping that
the user actually opens up explorer/finder/whatever and browses to some
folder deep within the profile directory, and then double clicks something?
Telling a user "click here and run blah to get a pony" is so much easier.

2009/11/12 Jonas Sicking <jonas@sicking.cc>

> 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.
> >
> > 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 can think of two security concerns if a website is able to store
> executable files with a proper .exe extension on windows:
> 1. It's happened several times in the past that exploits have made it
> possible to run a executable stored on the users system. If a website
> is able to first store an arbitrary executable and then execute it,
> that's much worse than being able to run the executables that live on
> the system already. In other words, being able to write a executable
> to the users system can be a important first step in a two-step
> attack.
> This could be fixed by 'salting' all the directory names. I.e. make
> the directory where the files are stored unguessable. We do this for
> the profile directories in Firefox.
> 2. Having a untrusted executable stored on the users system is
> somewhat scary. A user browsing around on his hard drive could easily
> accidentally run such an executable. Especially since the executable
> could contain a arbitrary icon, such as an icon similar some other
> program. Imagine for example writing a file called "skype.exe" with a
> skype icon being written. A user could very well accidentally find
> this while searching for skype on his/her computer.
>
> I think that if we were to implement something like this in firefox,
> we would probably never write executable files. Instead we would
> mangle their on-disk-name such that windows wouldn't recognize it as
> executable. (on mac/linux I think never setting the 'executable' flag
> would have the same effect). This could of course be hidden from the
> API, such that the web page API still saw a file with a proper .exe
> extension.
>
> There's quite possibly other issues like this as well. Writing .doc
> files with evil macros comes to mind.
>
> / Jonas
>
>