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 <w3c@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-apis@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
>
>