Re: Use Cases and Requirements for Saving Files Securely

On Mon, Nov 2, 2009 at 11:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Nov 2, 2009 at 12:48 PM, Doug Schepers <schepers@w3.org> wrote:
>> Hi, Folks-
>>
>> During the TPAC joint meeting between the WebApps and DAP WGs, we discussed
>> security policies and use cases and requirements around saving files in
>> different scenarios: public web resources (web pages and apps), widgets,
>> mobile device and desktop browsers, locally-installed applications, etc. [1]
>>
>> To kick this thread off, I'd like to suggest the trust model that already
>> exists for local applications and browsers, which is to open a modal dialog
>> that allows the user to select the file the application can save to; for
>> webapps, I suggest the extra security consideration we add is to have the
>> file hook which is returned is completely opaque (as far as the directory
>> and file name) to the web app, and it just knows where to write.  Further,
>> we should limit the upper bounds of the file size. I don't have any thoughts
>> about auto-save across sessions, but it should be addressed (probably not
>> allowed).

For a single-object save [Jonas's #1 below], I think this all sounds
good.  I'm not sure about the file size limit, though.  The user's
explicitly asked to save the file, and if it's too big, they'll know
what the problem is.  I could see requiring a page to state in advance
how big a file it wanted to save, so that the UA could warn the user
beforehand, but I think enforcing an arbitrary cap isn't flexible
enough.

I agree that auto-save across sessions should be ruled out for now.

I'd also like to emphasize that the ability to write a file shouldn't
confer the ability to read it.  You might be overwriting data that's
none of your business, and the UA can handle the "Are you sure?"
prompts.

>> This could be evoked through the UI convention of a file dialog, or just as
>> a bare API (if the user preferences allow the API to ask about saving
>> files).  In any case, it should never be a "cool" webapp-specific file API
>> dialog, only ever the native dialog of the browser (be it a desktop or
>> mobile).
>>
>> Please send in use cases, requirements, concerns, and concrete suggestions
>> about the general topic (regardless of your opinion about my suggestion).
>>
>> [1] http://www.w3.org/2009/11/02-dap-irc#T20-40-39-1
>
> It seems to me that there were (at least) two types of 'save' features
> being discussed today.
>
> 1. The ability for something like google docs to bring up a "save as"
> dialog to save the document in a user chosen location.
> 2. The ability for pages to write to a virtual filesystem using a
> location and name picked by the page.
>
> It sounds like you are primarily referring to the first of these, is
> that a correct understanding?
>
> I agree that this seems like a good place to start. You can actually
> do this already, although it's far from elegant:
>
> a = document.createElement('a');
> document.body.appendChild(a);
> a.href = "data:application/octet-stream;base64,...";
> a.click();
>
> I believe that will bring up the standard browser save-as dialog.
> Obviously it would be nice to have something better than that. I think
> what we need is something is:
>
> * A way to create a Blob object based on data created by the page.

Yes, absolutely.

> * An API that given a Blob shows a "safe file as" dialog to the user.

This is a little trickier. I think it would be better to require
asynchronous user intervention, rather than have a call that trivially
brings up a modal dialog.  How about a new HTML element similar to the
current selector for input files, but which when triggered by a user
action brings up a save-as dialog?  If that dialog triggered an event
that carried a writable file handle encapsulation [a FileWriter
similar to Arun's FileReader [1]], we could then pass it a blob to
complete the save.

It would be quite convenient if Jian Li's drag-out [2] and the save-as
dialog could share a similar interface.  I'm not quite sure what that
would look like, though...it would be simpler just to be able to point
the dataTransfer DownloadURL to a URN created from the source blob.
Currently in Arun's spec there's no way to go from blob to URN--urn is
a member on the derived interface File--but I've just posted a
suggestion [3] that we provide one.

> I think the former is something we'll need anyway, and once we have
> that the latter is an easy addition.

Agreed; we can build up in easy layers.

Arun's spec gives us file input, given a read handle.
#1 above gives us file output, given a write handle.
The next layer [#2 above] lets apps manage sandboxed local caches
without user intervention.  This would be a fine place to introduce
directories.
After that, we can consider access to the filesystem at large, a much
harder feature to get right.

     Eric

[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022118.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0506.html

Received on Thursday, 5 November 2009 23:55:01 UTC