Re: Use Cases and Requirements for Saving Files Securely
On Mon, 02 Nov 2009 21:48:58 +0100, Doug Schepers schep...@w3.org 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 URL: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: Rename “File API” to “FileReader API”?
On Wed, 11 Nov 2009 02:47:50 +0100, Maciej Stachowiak m...@apple.com wrote: I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via Save As dialog) Note that both explicit content and private use areas/sandboxes has security implications. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Rename “File API” to “FileReader API”?
On Nov 11, 2009, at 12:36 AM, Arve Bersvendsen wrote: On Wed, 11 Nov 2009 02:47:50 +0100, Maciej Stachowiak m...@apple.com wrote: I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via Save As dialog) Note that both explicit content and private use areas/sandboxes has security implications. Of course it does. Any new capability we add to the Web platform has security implications. For these particular features, I would like to see designed such that it is reasonable to expose them to public Web content, without the need for trust decisions by the user or policy choices by an administrator or network operator. I believe that is possible. When it comes to directory manipulation, I am not sure such a design is possible, or at least, I have not heard a good proposal yet. Regards, Maciej
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 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. 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: STS and lockCA
On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote: Gervase Markham wrote on 10/01/2009 5:51 PM: I therefore propose a simple extension to the STS standard; a single token to be appended to the end of the header: lockCA One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Adam
Re: STS and lockCA
One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. I am actually afraid that the website can easily miscompute that. In general, with STS , I am afraid of sites miscalculating some max-age like setting and taking themselves offline. Having browsers automatically expire STS at the same time as the cert makes sense to me. Sites that do their certs right do not lose any security properties and sites that mess up worst case fall back to old HTTP/HTTPS behaviour (and not take themselves offline). You could ofcourse argue that STS site's admin won't be stupid. While I wouldn't put my money on that, that's a assumption that the specification free to make but should be explicit about (for e.g by telling the spec reader : we are assuming you are smart, if you mess up you can easily take your site offline) Cheers Devdatta 2009/11/11 Adam Barth w...@adambarth.com: On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote: Gervase Markham wrote on 10/01/2009 5:51 PM: I therefore propose a simple extension to the STS standard; a single token to be appended to the end of the header: lockCA One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Adam
Re: [FileAPI] File.name
On Wed, 11 Nov 2009 02:39:46 +0100, Maciej Stachowiak m...@apple.com wrote: On Nov 10, 2009, at 5:29 PM, Anne van Kesteren wrote: The name of the file as a UTF8-encoded string. A DOMString is not UTF-8-encoded. I think this should just say Returns the filename. It is not more complicated than that as far as I can tell. There are some filesystems on (mostly legacy) Unix-like systems where filenames are stored in some other encoding than UTF-8, and in some cases the encoding is not even known. For example, in Japan there exist NFS fileservers where the filenames are encoded in Shift-JIS. In cases like that it's a little more complicated than Return the filename but it's probably ok to just leave it to the UA or the operating system to figure out how to deal. Interpreting it as UTF-8 is likely to be a poor choice in such cases. Also, that would you mean you'd have to decode it with UTF-8 as encoding, not encode. -- Anne van Kesteren http://annevankesteren.nl/
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
comments from Osmosoft on the File API
At Osmosoft, we took some time to collectively read the File API Editor's Working Draft 28 October 2009: http://dev.w3.org/2006/webapi/FileAPI/ Our interest in this specification stems from our contribution to the open source product TiddlyWiki -- an example of a Single Page Application (SPA), a concept we presented to the W3C Devices Workshop in December 2008: http://tiddlywiki.com http://www.w3.org/2008/security-ws/papers/osmosoft.html Overall we welcome the formalization of access to local files, including binary data within a client-side Web application and can envisage migrating a number of features currently implemented using access to a file:// URI TiddlyWiki if and when it becomes available in browser implementations. During our review we have one overall disappointment: whilst the Use Cases describe saving local files programatically, the specification does not provide any write methods. We wondered if these were to be provided in a later version or via extensions? --We now gather this is a topic of debate within the WG and with the DAP WG. We do have some very minor comments which we hope will help move the specification forward. * Status of this Document The Status section states this is the work of the Web Applications Working Group, but we were unable to find mention of the spec from the Working Group page, or in the list of chartered deliverables: http://www.w3.org/2008/webapps/ http://www.w3.org/2008/webapps/charter/webapps-deliverables.html What is the current expectation of the status of the published document? Is it on the Recommendation track, or will it be published as a Working Group Note? What is the relationship between the File API document and the File Upload API listed on the historical Web API WG page? http://www.w3.org/2006/webapi/ http://www.w3.org/TR/file-upload/ * Acknowledgements Where is the original document from Robin Berjon? A link to the input document may help us better understand the context of this specification. * Processing Models Much of the specification seems to be written in terms of pseudo-code steps. Whilst this follows the style of parts of the HTML 5 specification, and simplifies cloning a working implementation, it can make it harder to read and more difficult to write tests for than a series of assertions. I'd suggest wherever possible, replacing the processing steps with a set of inputs, observable changes of state and outputs, even if this does make the specification more verbose. * Conformance The terminology used for conformance currently links within the document, rather than to HTML 5 specification. We'd also suggest adopting the HTML 5 colours for terminology, internal and external references. A a frag-id for each individual assertion, along with a table listing all of the assertions at the end of the document useful when building test suites. * Normative references Along with the authors, it would be useful to have an indication of the current status of each of the documents referenced. Many seem to be still at working draft. HTH Paul -- http://blog.whatfettle.com http://osmosoft.com
Re: comments from Osmosoft on the File API
On Nov 11, 2009, at 7:30 AM, ext paul.dow...@bt.com wrote: During our review we have one overall disappointment: whilst the Use Cases describe saving local files programatically, the specification does not provide any write methods. We wondered if these were to be provided in a later version or via extensions? --We now gather this is a topic of debate within the WG and with the DAP WG. WebApps' File Upload deliverable and DAP's FileSystem API deliverable provide the basis for the groups' related spec work. You are correct that the use cases and work split are still a WIP. What is the current expectation of the status of the published document? WebApps' plan is a Recommendation. What is the relationship between the File API document and the File Upload API listed on the historical Web API WG page? Please see the following for WebApps' current publication status including File Upload: http://www.w3.org/2008/webapps/wiki/PubStatus Where is the original document from Robin Berjon? You may want to check the following CVS log: http://dev.w3.org/cvsweb/2006/webapi/FileUpload/source/ -Regards, Art Barstow
Re: STS and lockCA
On 11/11/09 08:57, Adam Barth wrote: Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Not to mention the fact that you normally don't actually want the LockCA to expire at exactly the same time as the cert, because you don't normally change certs over the second they expire! One would hope to be safely on the new cert a week or two before the expiry of the old one - at which point, the seeminly-simple expire when cert expires setting comes back to bite you. Gerv
[widgets] Draft Agenda for 12 November 2009 VC
Below is the draft agenda for the November 12 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/10/29-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public Agenda: 1. Review and tweak agenda 2. Announcements 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ a. Constrained specification of Icon element; Magnus Olsson (2-Nov) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0445.html http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0567.html 4. Widget Interface spec a. Test suite status http://dev.w3.org/cvsweb/2006/waf/widgets-api/tests/ b. Call for consensus to publish LC#2 of the TWI spec: http://dev.w3.org/2006/waf/widgets-api/ 5. View Modes Media Features spec: http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html a. Viewmode related issues; Magnus Olsson (2-Nov) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0446.html b. View modes security considerations; David Rogers (2-Nov) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0438.html 6. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. IRI normalization only for HTTP*?; Dominique Hazael-Massieux (2-Nov) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0442.html http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0443.html b. Comments to WARP spec; Bryan Sullivan (2-Nov) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0437.html c. local addresses, UPnP, comments; Marcin Hanclik (2-Nov) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0456.html 7. URI Scheme spec http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ a. LC comment period ended 10 November; plan to respond to comments 8. AOB
Re: Rename “File API” to “FileReader API”?
I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. From the F2F my understanding is that DAP will consider security as an integral part of API development, while also developing policy mechanisms, thus I do not think the view you mention is widely held. regards, Frederick Frederick Hirsch Nokia On Nov 10, 2009, at 8:47 PM, ext Maciej Stachowiak wrote: On Nov 10, 2009, at 3:09 AM, Robin Berjon wrote: On Nov 10, 2009, at 11:27 , Maciej Stachowiak wrote: On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote: On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth w...@adambarth.com wrote: Which is the proper mailing list to follow development of the file writing API? I'd like to follow it's security considerations. public-device-a...@w3.org At TPAC, I recall that we proposed drawing the line between file reading/writing on the one hand (presumably to go in the current File API spec) and filesystem access (including messing with directories, mountpoints, file renames etc) to be done in the Filesystem API spec. Do we need further discussion to settle what goes in which spec? No, we agreed that File Reader would keep going on in WebApps because there's no reason to move something that's making progress (unless Arun wants to move it, he's in both WGs anyway), but that the rest would be done in DAP since it's more security sensitive and new (and chartered there). I don't recall agreeing to that. I remember that we discussed multiple options, and I do not believe there was a resolution recorded along the lines of what you say. (But if I'm wrong, I guess the minutes will show. I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via Save As dialog). I think directory manipulation and opening of arbitrary files can't be fit into that security model and has to rely on a widget security model where there is an overall user trust decision. I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. I would also be concerned with tying file writing to directory manipulation, because I think the former is reasonable to do in browsers and not the latter. Perhaps this means that we need three specs? Regards, Maciej
Re: STS and lockCA
Gervase Markham wrote on 11/11/2009 6:28 AM: On 11/11/09 08:57, Adam Barth wrote: Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Not to mention the fact that you normally don't actually want the LockCA to expire at exactly the same time as the cert, because you don't normally change certs over the second they expire! One would hope to be safely on the new cert a week or two before the expiry of the old one - at which point, the seeminly-simple expire when cert expires setting comes back to bite you. Would LockCA prevent the site from loading if it encountered a new cert from the same CA? Or are you talking about a site that wants to switch CAs and is using LockCA? How about instead there's a way to set the max-age relative to the cert expiration? So -3024000 is two weeks before the cert expiration and 3024000 is two weeks after. I'm in agreement with Devdatta that it would be easy for someone to lock out their visitors, and I think this is easier to implement. - Bil
[widgets] Conformance testing results
Hi All, Daniel Silva and Samuel Santos have completed Phase 1 of compatibility testing. They've detailed their results as part of the conformance matrix [1]. We would like to publish the results as a working group note. Phase 2 will begin in about 3 weeks, in which we are hoping to start working with vendors to improve overall conformance. We need help with Phase 2: if you know a team contact for any of the targeted products that are claiming conformance to W3C Widgets, then would appreciate your help in making them aware of the results of the testing [1]. Kind regards, Marcos [1] http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html -- Marcos Caceres http://datadriven.com.au
Re: Use Cases and Requirements for Saving Files Securely
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. - 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? 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: Rename “File API” to “FileReader API”?
On Wed, Nov 11, 2009 at 12:44 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2009, at 12:36 AM, Arve Bersvendsen wrote: On Wed, 11 Nov 2009 02:47:50 +0100, Maciej Stachowiak m...@apple.com wrote: I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via Save As dialog) Note that both explicit content and private use areas/sandboxes has security implications. Of course it does. Any new capability we add to the Web platform has security implications. For these particular features, I would like to see designed such that it is reasonable to expose them to public Web content, without the need for trust decisions by the user or policy choices by an administrator or network operator. I believe that is possible. When it comes to directory manipulation, I am not sure such a design is possible, or at least, I have not heard a good proposal yet. Regards, Maciej How would you feel about a web app being able to write to a sandboxed per-origin filesystem with a small default quota and no prompt? Eric
Re: Rename “File API” to “FileReader API”?
On Nov 11, 2009, at 3:57 PM, Eric Uhrhane wrote: On Wed, Nov 11, 2009 at 12:44 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2009, at 12:36 AM, Arve Bersvendsen wrote: On Wed, 11 Nov 2009 02:47:50 +0100, Maciej Stachowiak m...@apple.com wrote: I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via Save As dialog) Note that both explicit content and private use areas/sandboxes has security implications. Of course it does. Any new capability we add to the Web platform has security implications. For these particular features, I would like to see designed such that it is reasonable to expose them to public Web content, without the need for trust decisions by the user or policy choices by an administrator or network operator. I believe that is possible. When it comes to directory manipulation, I am not sure such a design is possible, or at least, I have not heard a good proposal yet. Regards, Maciej How would you feel about a web app being able to write to a sandboxed per-origin filesystem with a small default quota and no prompt? I think that is a reasonable feature with relatively low risk, but the devil is in the details. Here are some possible risk factors: 1) If the Web app can control the file name and/or metadata (such as file type or icon) as well as the contents, it could put files on disk that are very dangerous for the user to double-click. (Of course, downloads partially give that capability but browsers typically examine content being downloaded and give extra warnings about dangerous types). Imagine laying down a trojan .exe with the same icon as your music files. This risk does not exist with LocalStorage or WebDatabase, and could be eliminated by giving the Web app no control over the real on-disk filename, but of course that would get in the way of sharing files with native applications. 2) Directory manipulation features would have to be carefully constructed to avoid risk of breaking out of the sandbox. 3) Directory creation may contribute to disk space use in a way that is hard to measure. That's just off the top of my head. Regards, Maciej
Re: Use Cases and Requirements for Saving Files Securely
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. 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
Re: Rename “File API” to “FileReader API”?
On Wed, Nov 11, 2009 at 7:23 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2009, at 3:57 PM, Eric Uhrhane wrote: On Wed, Nov 11, 2009 at 12:44 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2009, at 12:36 AM, Arve Bersvendsen wrote: On Wed, 11 Nov 2009 02:47:50 +0100, Maciej Stachowiak m...@apple.com wrote: I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via Save As dialog) Note that both explicit content and private use areas/sandboxes has security implications. Of course it does. Any new capability we add to the Web platform has security implications. For these particular features, I would like to see designed such that it is reasonable to expose them to public Web content, without the need for trust decisions by the user or policy choices by an administrator or network operator. I believe that is possible. When it comes to directory manipulation, I am not sure such a design is possible, or at least, I have not heard a good proposal yet. Regards, Maciej How would you feel about a web app being able to write to a sandboxed per-origin filesystem with a small default quota and no prompt? I think that is a reasonable feature with relatively low risk, but the devil is in the details. Here are some possible risk factors: 1) If the Web app can control the file name and/or metadata (such as file type or icon) as well as the contents, it could put files on disk that are very dangerous for the user to double-click. (Of course, downloads partially give that capability but browsers typically examine content being downloaded and give extra warnings about dangerous types). Imagine laying down a trojan .exe with the same icon as your music files. This risk does not exist with LocalStorage or WebDatabase, and could be eliminated by giving the Web app no control over the real on-disk filename, but of course that would get in the way of sharing files with native applications. 2) Directory manipulation features would have to be carefully constructed to avoid risk of breaking out of the sandbox. 3) Directory creation may contribute to disk space use in a way that is hard to measure. That's just off the top of my head. Regards, Maciej Yup; those are all quite valid concerns. I think we can mitigate the risk of #1 without messing with filenames [e.g. Windows' Zone.Identifier], but of course there's no way to eliminate it entirely. For #3 we could have a directory [and/or file] count quota in addition to the file content quota, or could just let the UA choose how to present the problem to the user.
Re: [fileapi] urn - URL
Anne van Kesteren wrote: I don't see a reason why we should call the member urn. URL is much more consistent with other parts of the Web platform and works just as well. I thought we agreed on this previously so I'm just mentioning it here since it seems to have changed again. URN seems to be fine as long the identifier actually *is* a URN (which it currently is). That being said, and as mentioned before, I'm still not convinced that the spec needs to recommend a specific URI scheme. We have talked about that before; is there something in the mailing list archives that actually summarizes why this is needed? Finally, *at this time* (while it *is* a URN) renaming to URL would be inconsistent with the relevant base specs, and produce even more confusion. The right thing to do here is to stay consistent with WebArch and RFC 3986, thus fix the terminology in HTML5. BR, Julian
