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

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

Received on Wednesday, 11 November 2009 01:48:24 UTC