File writing ponderings (was: Re: Security evaluation of an example DAP policy)

Starting a new thread since the other one was more of a
meta-discussion, this one has more technical meat on it.

On Fri, Nov 20, 2009 at 9:23 AM, Robin Berjon <robin@berjon.com> wrote:
> 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).

My main concern with this idea is that I'm not sure how to make it
clear to the user that access is granted both for reading and writing.

> It could be that the initial save happens through a download dialog — something which users are familiar with.

This I like better. More below.

> 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.

Hmm.. This is a very interesting idea. Definitely worth exploring more.

What I had in mind was basically something like this:

1. An API for creating File objects by concatinating strings, Blobs,
ByteArrays (or whatever they'll be called, see Maciejs proposals to
public-webapps and public-script-coord). A mimetype and a default name
(possibly without extension) would also be assigned to the File in
some fashion.
2. A API that given a File object brings up the normal "Safe File As" dialog.

/ Jonas

Received on Saturday, 21 November 2009 08:27:08 UTC