W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Re: Rename “File API” to “FileReader API”?

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 11 Nov 2009 19:23:58 -0800
Cc: Arve Bersvendsen <arveb@opera.com>, Robin Berjon <robin@berjon.com>, public-device-apis@w3.org, public-webapps WG <public-webapps@w3.org>
Message-id: <E6CD5C38-D0EC-490E-90C0-C6E319EA4670@apple.com>
To: Eric Uhrhane <ericu@google.com>

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.

Received on Thursday, 12 November 2009 03:24:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:40 UTC