W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Re: Security evaluation of an example DAP policy

From: Robin Berjon <robin@berjon.com>
Date: Fri, 20 Nov 2009 18:23:11 +0100
Cc: public-device-apis@w3.org, public-webapps WG <public-webapps@w3.org>
Message-Id: <A29AD505-63DE-4DE9-AFA4-755D5C4EC93E@berjon.com>
To: Adam Barth <w3c@adambarth.com>
On Nov 20, 2009, at 17:40 , Adam Barth wrote:
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon <robin@berjon.com> wrote:
>> DAP will handle security at the API definition level. Full stop.
> 
> Can you elaborate on what this means concretely?  For example, how is
> security handled at the API definition level for the file writing API?

Well, if you're asking me to define how we're going to do it for all the APIs before they've been written, it's gonna be a smidge hard :)

I've been noodling a little bit over the file writing case, and have some ideas that at this stage involve hand-waving, have not been validated by the WG or in fact anyone else, and are subject to change (I only took on the action to work on this yesterday, and haven't really sat down to do it right yet).

One idea, which Max had, was to tack this onto <input type=file>. The file browsing dialog we have today would work the same, but would have an extra checkbox (unchecked by default) saying "Enable writing back to this file". The file object would become available in the same way as for reading, but would also support writing. It has limited but real use cases, such as loading a document (HTML, image, whatever) which can be edited in the page and saved back. The problem is that it doesn't allow for creating a new document (the initial save)  I haven't cracked that one yet (creating new files, even if they can't overwrite existing ones, has clear issues). It could be that the initial save happens through a download dialog  something which users are familiar with.

Another option I had in mind was an extension to Element, e.g. Element.attachData(someFileObject). Said element would then, when dragged out of the browser, drop the content of the file there. It's been a while since I've looked at ongoing work on the cut-paste/drag-drop stuff and I've been meaning to take a good look at it precisely for this. I suspect that if the security issues are solved for those, then we might be able to piggy back on them to create files safely. But that's just a braindump.

I'm sorry if this all feels handwavy but if you're looking for assurance that things that haven't been defined yet are good, I can't give it. All I give is the assurance that the *principles* are there, and will be enforced.

-- 
Robin Berjon - http://berjon.com/
Received on Friday, 20 November 2009 17:23:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT