- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 12 Nov 2009 01:40:33 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Eric Uhrhane <ericu@google.com>, Ian Hickson <ian@hixie.ch>, Doug Schepers <schepers@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, public-device-apis@w3.org
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
Received on Thursday, 12 November 2009 09:41:27 UTC