Re: Rename "File API" to "FileReader API"?

On Wed, Nov 11, 2009 at 7:23 PM, Maciej Stachowiak <mjs@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 <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

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.

Received on Thursday, 12 November 2009 04:31:27 UTC