- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 11 Nov 2009 19:23:58 -0800
- To: Eric Uhrhane <ericu@google.com>
- Cc: Arve Bersvendsen <arveb@opera.com>, Robin Berjon <robin@berjon.com>, public-device-apis@w3.org, public-webapps WG <public-webapps@w3.org>
On Nov 11, 2009, at 3:57 PM, Eric Uhrhane wrote: > On Wed, Nov 11, 2009 at 12:44 AM, Maciej Stachowiak <mjs@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 >>> <mjs@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
Received on Thursday, 12 November 2009 03:24:45 UTC