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 <jo...@sicking.cc> > On Wed, Nov 11, 2009 at 6:59 PM, Maciej Stachowiak <m...@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 <m...@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 > >
