Re: Use Cases and Requirements for Saving Files Securely
On Wed, 11 Nov 2009 09:51:56 +0100, Maciej Stachowiak wrote: On Nov 10, 2009, at 11:45 PM, Charles McCathieNevile wrote: On Tue, 10 Nov 2009 01:21:06 +0100, Maciej Stachowiak 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. I would like to expand them a little, in each case making it possible to use existing content, or expose content directly to the user enabling them to change the software they use, or even use multiple tools on the same content - a web app one day, a different one next week, a piece of shrink-wrap software from time to time. I'm having trouble following. Could you give more specific examples of what you have in mind? * Ability to make a web-based mail interface that has access to the actual files that my local mail client has. * Ability to make a web-based audio player that lets me play the audio I already own (but with a different UI accessing different metadata), which have been filed by iTunes in a set of directories on my local drive. Does your expansion imply new requirements, on top of either Ian's list or my list? As I understand it, your list is just a restriction of Ian's. I am not sure if this requires an extension of Ian's list - I am listing the things I am actually trying to do or know of people actually working on, before trying to get the requirements for each different approach. And add: * A document management system as hybrid web app, allowing file-based access to the documents as well. I don't exactly follow this either. By "hybrid web app", do you mean something running locally with some portion of native code doing part of the job? No, I mean a web-app running as a web app, which assumes that other applications, some local, will want to use the document. For example, I use several different applications to interact with images, with PDF documents and Documents in Word/OpenOffice formats, depending on what I am doing with the document at the time. I would like to add to that range of applications the ability to use a web-app without having to maintain separate copies - synching is even harder than managing my file system. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Use Cases and Requirements for Saving Files Securely
2009/11/12 Ian Fette (イアンフェッティ) : > 2009/11/12 Jonas Sicking >> >> 2009/11/12 Ian Fette (イアンフェッティ) : >> > 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. >> >> So first off that only addresses one of the two attacks I listed. >> > > Fair > >> >> But even that case I don't think is that fantasy-y. The whole point of >> writing actual files is so that users can interact with the files, >> right? In doing so they'll be just a double-click away from running >> arbitrary malicious code. No warning dialogs or anything. Instead the > > Why do you assume this? On Windows, we can write the MotW identifier, which > would lead to windows showing a warning. On linux, we could refuse to chmod > +x. Ah, don't know enough about this feature so can't really comment. All the information I found was regarding MotW on webpages, not on executables. / Jonas
Re: Use Cases and Requirements for Saving Files Securely
2009/11/12 Jonas Sicking > 2009/11/12 Ian Fette (イアンフェッティ) : > > 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. > > So first off that only addresses one of the two attacks I listed. > > Fair > But even that case I don't think is that fantasy-y. The whole point of > writing actual files is so that users can interact with the files, > right? In doing so they'll be just a double-click away from running > arbitrary malicious code. No warning dialogs or anything. Instead the > Why do you assume this? On Windows, we can write the MotW identifier, which would lead to windows showing a warning. On linux, we could refuse to chmod +x. > attacker has a range of social engineering opportunities using file > icon and name as to make doubleclicking the file inviting. > > Like I said, I think this might be possible to work around in the > implementation by making sure to neuter all executable files before > they go to disk. > > / Jonas >
Re: Use Cases and Requirements for Saving Files Securely
2009/11/12 Jonas Sicking : > 2009/11/12 Ian Fette (イアンフェッティ) : >> 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. > > So first off that only addresses one of the two attacks I listed. > > But even that case I don't think is that fantasy-y. The whole point of > writing actual files is so that users can interact with the files, > right? In doing so they'll be just a double-click away from running > arbitrary malicious code. No warning dialogs or anything. Instead the > attacker has a range of social engineering opportunities using file > icon and name as to make doubleclicking the file inviting. > > Like I said, I think this might be possible to work around in the > implementation by making sure to neuter all executable files before > they go to disk. Keep in mind that some users interact with their file systems via search, not browse. For example, if I use Quicksilver or Spotlight to launch skype.exe (sorry for mixing platforms), I might easily launch the skype.exe buried in my profile instead of the one in Program Files. Adam
Re: Use Cases and Requirements for Saving Files Securely
On Thu, 12 Nov 2009 10:59:04 +0100, Jonas Sicking wrote: Like I said, I think this might be possible to work around in the implementation by making sure to neuter all executable files before they go to disk. I'm not sure it's possible to make complete workarounds. In the idealized case, Linux depends on the execute being set. Many desktop users will have wine installed, though, in which case the wine program loader will pick up and execute the file, regardless of any extension. (It can of course be argued that this is a fundamental problem of how wine is set up to integrate with the OS) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Use Cases and Requirements for Saving Files Securely
2009/11/12 Ian Fette (イアンフェッティ) : > 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. So first off that only addresses one of the two attacks I listed. But even that case I don't think is that fantasy-y. The whole point of writing actual files is so that users can interact with the files, right? In doing so they'll be just a double-click away from running arbitrary malicious code. No warning dialogs or anything. Instead the attacker has a range of social engineering opportunities using file icon and name as to make doubleclicking the file inviting. Like I said, I think this might be possible to work around in the implementation by making sure to neuter all executable files before they go to disk. / Jonas
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 > On Wed, Nov 11, 2009 at 6:59 PM, Maciej Stachowiak wrote: > > > > On Nov 11, 2009, at 3:51 PM, Eric Uhrhane wrote: > > > >> On Mon, Nov 9, 2009 at 4:21 PM, Maciej Stachowiak > 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 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 n
Re: Use Cases and Requirements for Saving Files Securely
On Wed, Nov 11, 2009 at 6:59 PM, Maciej Stachowiak wrote: > > On Nov 11, 2009, at 3:51 PM, Eric Uhrhane wrote: > >> On Mon, Nov 9, 2009 at 4:21 PM, Maciej Stachowiak 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 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
Re: Use Cases and Requirements for Saving Files Securely
On Wed, Nov 11, 2009 at 6:59 PM, Maciej Stachowiak wrote: > > On Nov 11, 2009, at 3:51 PM, Eric Uhrhane wrote: > >> On Mon, Nov 9, 2009 at 4:21 PM, Maciej Stachowiak 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 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 >>> ). >>> >>> 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
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 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 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 ). 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 tand
Re: Use Cases and Requirements for Saving Files Securely
On Mon, Nov 9, 2009 at 4:21 PM, Maciej Stachowiak 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 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. > - Ability to write to a user-selected file (perhaps using something like > ). > > 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? 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. 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. >> 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
RE: Use Cases and Requirements for Saving Files Securely
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). We presented a paper on behalf of TiddlyWiki, an example Single Page Application at the devices workshop last year: http://www.w3.org/2008/security-ws/papers/osmosoft.html TiddlyWiki makes use of a number of file system features currently accesed through a variety of browser specific tactics including a signed applet, which for reasons of security, simplifying the user interface and to ensure continued support for our large user base we would like to see formalized in a standard File API, in particular: - The ability to "save" themselves, by writing back to the originating file URI, following being granted privileges, - The ability to create and write adjunct text files in the same directory, such as an RSS feed, hcard, ics and RTF documents, - Ideally we'd like the ability to read, manipulate and write binary files, such as images, PDF files and tags in audio and other media files. >From our position, the proposed File API looked good in terms of the Use Cases section which covered the above, and the File object, though on closer inspection the specification did not include any APIs for writing, which puzzled us greatly. Given the value of the core of this specification in holding and manipulating files in memory, I'd be inclined to suggest keeping the name "File API" and provide simple write methods. Maybe the more complex issue of access control could be provided as a separate specification, given that's a generic issue for the DAP? -- Paul (psd) http://blog.whatfettle.com http://osmosoft.com
Re: Use Cases and Requirements for Saving Files Securely
On Nov 10, 2009, at 11:45 PM, Charles McCathieNevile wrote: On Tue, 10 Nov 2009 01:21:06 +0100, Maciej Stachowiak 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. I would like to expand them a little, in each case making it possible to use existing content, or expose content directly to the user enabling them to change the software they use, or even use multiple tools on the same content - a web app one day, a different one next week, a piece of shrink-wrap software from time to time. I'm having trouble following. Could you give more specific examples of what you have in mind? Does your expansion imply new requirements, on top of either Ian's list or my list? And add: * A document management system as hybrid web app, allowing file- based access to the documents as well. I don't exactly follow this either. By "hybrid web app", do you mean something running locally with some portion of native code doing part of the job? Assuming that is what you mean: I think hybrid Web apps are extremely interesting (and something Apple supports and encourages on Mac OS X and iPhone OS), but they should not be used the sole use case for any API that we wish to expose to public Web content. The reason is that on the one hand, hybrid Web apps are not constrained by the Web security model, and on the other hand, they are always free to break out of the sandbox with native code, or capabilities specific to a particular runtime. For functionality we expose to the Web, there should be at least some justifying use cases that are pure Web apps. Regards, Maciej
Re: Use Cases and Requirements for Saving Files Securely
On Mon, 02 Nov 2009 21:48:58 +0100, Doug Schepers wrote: Please send in use cases, requirements, concerns, and concrete suggestions about the general topic (regardless of your opinion about my suggestion). One concern: There are historical vulnerabilities, such as http://secunia.com/advisories/10968/> wherein a system could be compromised by the user navigating to a folder containing a malicious file, using the system's default file navigator. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Use Cases and Requirements for Saving Files Securely
On Tue, 10 Nov 2009 01:21:06 +0100, Maciej Stachowiak 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. I would like to expand them a little, in each case making it possible to use existing content, or expose content directly to the user enabling them to change the software they use, or even use multiple tools on the same content - a web app one day, a different one next week, a piece of shrink-wrap software from time to time. And add: * A document management system as hybrid web app, allowing file-based access to the documents as well. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Use Cases and Requirements for Saving Files Securely
On Tue, 10 Nov 2009 21:36:36 +0100, Ian Hickson wrote: On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote: Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit : > Some use cases: > […] > * 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 Note that these three use cases would be potentially better addressed by the potential Media/Gallery API the group is supposed to work on (“Gallery API, an API to manage the local media file storage” in our charter [1]). Wouldn't such an API be over-specialisation? Depends how deeply people care about specific types. It seems the general feeling in HTML is that knowing something is a video, rather than just an embedded object, is enough to add an element for it, so probably not although one would *hope* that there were a general framework behind such an API to allow mutiple (over-)specialised access APIs to be developed as deemed useful. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Use Cases and Requirements for Saving Files Securely
On Tue, Nov 10, 2009 at 5:53 PM, Maciej Stachowiak wrote: > > On Nov 10, 2009, at 12:36 PM, Ian Hickson wrote: > >> On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote: >>> >>> Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit : Some use cases: […] * 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 >>> >>> Note that these three use cases would be potentially better addressed by >>> the potential Media/Gallery API the group is supposed to work on >>> (“Gallery API, an API to manage the local media file storage” in our >>> charter [1]). >> >> Wouldn't such an API be over-specialisation? > > Many modern platforms (well, at least iPhone and Mac OS X) have APIs to > manipulate a system notion of media gallery. We have considered exposing the > ability to choose from the user's media collection via , > possibly keying off of accept="image/*" or "audio/*" or "video/*". It would be awesome if you exposed it that way. That's exactly what we have in mind too at mozilla. Won't happen in the Firefox 3.6 release, but hopefully not long after that. / Jonas
Re: Use Cases and Requirements for Saving Files Securely
On Nov 10, 2009, at 12:36 PM, Ian Hickson wrote: On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote: Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit : Some use cases: […] * 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 Note that these three use cases would be potentially better addressed by the potential Media/Gallery API the group is supposed to work on (“Gallery API, an API to manage the local media file storage” in our charter [1]). Wouldn't such an API be over-specialisation? Many modern platforms (well, at least iPhone and Mac OS X) have APIs to manipulate a system notion of media gallery. We have considered exposing the ability to choose from the user's media collection via , possibly keying off of accept="image/*" or "audio/ *" or "video/*". I think an API to freely add and remove items from the media collection is something we might not be comfortable with exposing to the Web, for security reasons. We might consider an API to save to the media collection as long as there is user control. Regards, Maciej
Re: Use Cases and Requirements for Saving Files Securely
On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote: > Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit : > > Some use cases: > > […] > > * 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 > > Note that these three use cases would be potentially better addressed by > the potential Media/Gallery API the group is supposed to work on > (“Gallery API, an API to manage the local media file storage” in our > charter [1]). Wouldn't such an API be over-specialisation? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Use Cases and Requirements for Saving Files Securely
Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit : > Some use cases: > […] > * 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 Note that these three use cases would be potentially better addressed by the potential Media/Gallery API the group is supposed to work on (“Gallery API, an API to manage the local media file storage” in our charter [1]). Dom — hello DAP’s ISSUE-39 1. http://www.w3.org/2009/05/DeviceAPICharter
Re: Use Cases and Requirements for Saving Files Securely
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 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). - Ability to write to a user-selected file (perhaps using something like ). 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. 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. Regards, Maciej
Re: Use Cases and Requirements for Saving Files Securely
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 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 I'd be happy to volunteer to edit the Directory component of this, working in tandem with Arun's draft for file access. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Use Cases and Requirements for Saving Files Securely
On Mon, Nov 2, 2009 at 11:01 PM, Jonas Sicking wrote:
> On Mon, Nov 2, 2009 at 12:48 PM, Doug Schepers wrote:
>> Hi, Folks-
>>
>> During the TPAC joint meeting between the WebApps and DAP WGs, we discussed
>> security policies and use cases and requirements around saving files in
>> different scenarios: public web resources (web pages and apps), widgets,
>> mobile device and desktop browsers, locally-installed applications, etc. [1]
>>
>> To kick this thread off, I'd like to suggest the trust model that already
>> exists for local applications and browsers, which is to open a modal dialog
>> that allows the user to select the file the application can save to; for
>> webapps, I suggest the extra security consideration we add is to have the
>> file hook which is returned is completely opaque (as far as the directory
>> and file name) to the web app, and it just knows where to write. Further,
>> we should limit the upper bounds of the file size. I don't have any thoughts
>> about auto-save across sessions, but it should be addressed (probably not
>> allowed).
For a single-object save [Jonas's #1 below], I think this all sounds
good. I'm not sure about the file size limit, though. The user's
explicitly asked to save the file, and if it's too big, they'll know
what the problem is. I could see requiring a page to state in advance
how big a file it wanted to save, so that the UA could warn the user
beforehand, but I think enforcing an arbitrary cap isn't flexible
enough.
I agree that auto-save across sessions should be ruled out for now.
I'd also like to emphasize that the ability to write a file shouldn't
confer the ability to read it. You might be overwriting data that's
none of your business, and the UA can handle the "Are you sure?"
prompts.
>> This could be evoked through the UI convention of a file dialog, or just as
>> a bare API (if the user preferences allow the API to ask about saving
>> files). In any case, it should never be a "cool" webapp-specific file API
>> dialog, only ever the native dialog of the browser (be it a desktop or
>> mobile).
>>
>> Please send in use cases, requirements, concerns, and concrete suggestions
>> about the general topic (regardless of your opinion about my suggestion).
>>
>> [1] http://www.w3.org/2009/11/02-dap-irc#T20-40-39-1
>
> It seems to me that there were (at least) two types of 'save' features
> being discussed today.
>
> 1. The ability for something like google docs to bring up a "save as"
> dialog to save the document in a user chosen location.
> 2. The ability for pages to write to a virtual filesystem using a
> location and name picked by the page.
>
> It sounds like you are primarily referring to the first of these, is
> that a correct understanding?
>
> I agree that this seems like a good place to start. You can actually
> do this already, although it's far from elegant:
>
> a = document.createElement('a');
> document.body.appendChild(a);
> a.href = "data:application/octet-stream;base64,...";
> a.click();
>
> I believe that will bring up the standard browser save-as dialog.
> Obviously it would be nice to have something better than that. I think
> what we need is something is:
>
> * A way to create a Blob object based on data created by the page.
Yes, absolutely.
> * An API that given a Blob shows a "safe file as" dialog to the user.
This is a little trickier. I think it would be better to require
asynchronous user intervention, rather than have a call that trivially
brings up a modal dialog. How about a new HTML element similar to the
current selector for input files, but which when triggered by a user
action brings up a save-as dialog? If that dialog triggered an event
that carried a writable file handle encapsulation [a FileWriter
similar to Arun's FileReader [1]], we could then pass it a blob to
complete the save.
It would be quite convenient if Jian Li's drag-out [2] and the save-as
dialog could share a similar interface. I'm not quite sure what that
would look like, though...it would be simpler just to be able to point
the dataTransfer DownloadURL to a URN created from the source blob.
Currently in Arun's spec there's no way to go from blob to URN--urn is
a member on the derived interface File--but I've just posted a
suggestion [3] that we provide one.
> I think the former is something we'll need anyway, and once we have
> that the latter is an easy addition.
Agreed; we can build up in easy layers.
Arun's spec gives us file input, given a read handle.
#1 above gives us file output, given a write handle.
The next layer [#2 above] lets apps manage sandboxed local caches
without user intervention. This would be a fine place to introduce
directories.
After that, we can consider access to the filesystem at large, a much
harder feature to get right.
Eric
[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022118.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2
Re: Use Cases and Requirements for Saving Files Securely
On Mon, Nov 2, 2009 at 12:48 PM, Doug Schepers wrote:
> Hi, Folks-
>
> During the TPAC joint meeting between the WebApps and DAP WGs, we discussed
> security policies and use cases and requirements around saving files in
> different scenarios: public web resources (web pages and apps), widgets,
> mobile device and desktop browsers, locally-installed applications, etc. [1]
>
> To kick this thread off, I'd like to suggest the trust model that already
> exists for local applications and browsers, which is to open a modal dialog
> that allows the user to select the file the application can save to; for
> webapps, I suggest the extra security consideration we add is to have the
> file hook which is returned is completely opaque (as far as the directory
> and file name) to the web app, and it just knows where to write. Further,
> we should limit the upper bounds of the file size. I don't have any thoughts
> about auto-save across sessions, but it should be addressed (probably not
> allowed).
>
> This could be evoked through the UI convention of a file dialog, or just as
> a bare API (if the user preferences allow the API to ask about saving
> files). In any case, it should never be a "cool" webapp-specific file API
> dialog, only ever the native dialog of the browser (be it a desktop or
> mobile).
>
> Please send in use cases, requirements, concerns, and concrete suggestions
> about the general topic (regardless of your opinion about my suggestion).
>
> [1] http://www.w3.org/2009/11/02-dap-irc#T20-40-39-1
It seems to me that there were (at least) two types of 'save' features
being discussed today.
1. The ability for something like google docs to bring up a "save as"
dialog to save the document in a user chosen location.
2. The ability for pages to write to a virtual filesystem using a
location and name picked by the page.
It sounds like you are primarily referring to the first of these, is
that a correct understanding?
I agree that this seems like a good place to start. You can actually
do this already, although it's far from elegant:
a = document.createElement('a');
document.body.appendChild(a);
a.href = "data:application/octet-stream;base64,...";
a.click();
I believe that will bring up the standard browser save-as dialog.
Obviously it would be nice to have something better than that. I think
what we need is something is:
* A way to create a Blob object based on data created by the page.
* An API that given a Blob shows a "safe file as" dialog to the user.
I think the former is something we'll need anyway, and once we have
that the latter is an easy addition.
/ Jonas
Use Cases and Requirements for Saving Files Securely
Hi, Folks- During the TPAC joint meeting between the WebApps and DAP WGs, we discussed security policies and use cases and requirements around saving files in different scenarios: public web resources (web pages and apps), widgets, mobile device and desktop browsers, locally-installed applications, etc. [1] To kick this thread off, I'd like to suggest the trust model that already exists for local applications and browsers, which is to open a modal dialog that allows the user to select the file the application can save to; for webapps, I suggest the extra security consideration we add is to have the file hook which is returned is completely opaque (as far as the directory and file name) to the web app, and it just knows where to write. Further, we should limit the upper bounds of the file size. I don't have any thoughts about auto-save across sessions, but it should be addressed (probably not allowed). This could be evoked through the UI convention of a file dialog, or just as a bare API (if the user preferences allow the API to ask about saving files). In any case, it should never be a "cool" webapp-specific file API dialog, only ever the native dialog of the browser (be it a desktop or mobile). Please send in use cases, requirements, concerns, and concrete suggestions about the general topic (regardless of your opinion about my suggestion). [1] http://www.w3.org/2009/11/02-dap-irc#T20-40-39-1 Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
