> 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 > >Received on Wednesday, 11 November 2009 14:53:57 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC