(wrong string) “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.