Re: First stab at File Writer

On Mon, Dec 7, 2009 at 7:58 AM, Robin Berjon <robin@robineko.com> wrote:
> Hi Richard,
>
> On Dec 4, 2009, at 12:58 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com> wrote:
>> In terms of extending that, and according to the programmatic example
>> provided of requesting to write a 'dahut.txt' file, what is the context
>> of dahut.txt?
>
> It is a *suggested* name for the file, which the user can then store anywhere. The reason it is only a suggestion is because UAs are encouraged to change the name in untrusted situations, if it doesn't seem to follow a sane pattern, or if its extension and its media type don't match (or yet again, if the media type is considered dangerous). The user is granted full liberty to save it wherever since the author knows nothing of the underlying FS.
>
>> As a user I would then be able to provide permission for this action
>> against either/both the sandbox and/or the file being requested:
>>
>> - allow write to this file (for the current site/session only)
>> AND/OR
>> - allow write to this sandbox (for the current site/session only)
>
> I don't think that at this level we yet have a safe way of writing arbitrary files to a user-level directory (especially not stuff like My Documents). Not from a browser I mean.
>
> The sequel spec for this one handles directory tree manipulation, including creating files. It also specifies localFS which is a sandboxed FS proper. And more importantly, it has the unsafe stuff that widgets may want to use in it.
>
>> Going further, some sandboxes may be implicitly writable such as the
>> site:// temp sandbox.
>
> If something's temp, it should be an implementation detail that authors don't see. For instance, you might create a Blob (which has an in-memory metaphor) but the UA, seeing it grow, may decide to make it a temp file. Once you have that behaviour, do you really need your own temp files?

I think there is actually a solid use case for having both temporary
and non-temporary storage areas in the directory/sandbox spec.  I also
think Richard's idea of a shared area is quite interesting, but I'd
leave it for later expansions--there are a lot of interesting
possibilities there, but they'll take some time to work out.

If stuff stored in the app's /tmp can be deleted by the UA at need,
but will otherwise generally outlive the page, then it can be given
quite a liberal quota policy.  A UA might decide to allow some
reasonable amount of /tmp storage to all apps without bugging the
user, knowing that it can clean up if there's ever disk pressure, or
if the space is abused.  Apps that are written to require local files
can function right away, without the user responding to any
storage-request prompts.  They can later copy their files into the
non-temporary storage if the user decides that they're important
enough to keep.  The UA might then require user intervention to allow
any non-temporary storage at all.  Once it's allowed, it should be
safe from deletion by the UA without the user's permission.

The temporary storage can of course be used for cookie-resurrection
attacks, so UAs should make sure to present the option of clearing it
when the user clears any other origin-specific storage, blocking
access to it when cookies are blocked, etc.

    Eric

>> I also think this could satisfy a number of use cases from e.g. BONDI.
>
> I think that the BONDI use cases will be addressed by the conjunction of this spec and the directory navigation one. The advantage of the split is that safe/browser systems can implement only the first one (or that plus safe parts of the other).
>
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
>
>
>
>
>
>

Received on Wednesday, 9 December 2009 23:56:28 UTC