Re: Transferring File* to WebApps - redux

On Fri, Jun 18, 2010 at 10:53 AM, SULLIVAN, BRYAN L (ATTCINW)
<BS3131@att.com> wrote:
> Eric,
> Based upon your responses there are a couple of additional things we
> need to check on, but I'll look deeper into the current specs for the
> things that should already be supported.
>
> The additional things are:
>
> - how to safely grant access "outside the sandbox", which depends upon
> ability to discover available file systems in persistent storage and
> select arbitrary locations within them. We would prefer that this
> functional capability is addressed within the File* APIs directly rather
> than through an extension API in DAP, thus we may propose two additional
> methods for the LocalFilesystem interface:
>   getDefaultLocation: as from
> http://bondi.omtp.org/1.1/apis/filesystem.html#getDefaultLocationN101E4
>   getRootLocations: as from
> http://bondi.omtp.org/1.1/apis/filesystem.html#getRootLocationsN10253
> These methods can be covered under the general one-time prompt approach
> or under the policy approach (once we have worked out how the File* APIs
> are covered under that, e.g. by association of widget feature URIs).

Given that these methods would have security implications well beyond
the current spec, I'd prefer to have them added in a later pass,
either in an extension spec or in a later version of the filesystem
spec.  We've got enough to argue about in there already, and if we try
to do too much in one pass, we'll bog down.  These certainly look like
logical extensions to what we've been discussing, though.

> - clarify the difference between "memory" and "persistent storage": "In
> memory" usually means the content is in the working RAM of a device. The
> File* specs talk about working with files "in memory" which I take to
> mean that the file has been read from persistent storage into the
> working memory of the browser (upon selection by the user), and is being
> read or updated (with presumed writing back to persistent storage
> later). The different may be subtle but is important. If what's meant
> instead of a file copy "in memory" is that the webapp can *directly*
> access/update a file in persistent storage, then I suggest the spec
> terminology be updated to make that clear.

Arun: in 5.4 and 5.5.1, I think you want to change "in memory" to
"into memory" to match the other 15-or-so instances of that phrase in
the spec.  Bryan, is that sufficient?

> Thanks,
> Bryan Sullivan | AT&T
>
>
> -----Original Message-----
> From: Eric Uhrhane [mailto:ericu@google.com]
> Sent: Wednesday, June 16, 2010 4:42 PM
> To: SULLIVAN, BRYAN L (ATTCINW)
> Cc: arun@mozilla.com; Robin Berjon; public-device-apis@w3.org; Ian
> Fette; Web Applications Working Group WG
> Subject: Re: Transferring File* to WebApps - redux
>
> Sorry about the delay in response; I've been out of the office for the
> past 10 days.  [Also, sorry Bryan--I forgot to reply-all.]
>
> On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW)
> <BS3131@att.com> wrote:
>> I am not meaning to be unfair, perhaps the message is not coming
> through
>> clearly enough.
>>
>> There are specific technical requirements that we need these APIs to
>> fulfill, that I indicated to Thomas in another email:
>> 1) access filesystems on the host device
>
> FileSystem/FileWriter/FileReader do this.
>
>> 2) traverse directories
>
> FileSystem does this.  Currently it's only specced to do so within a
> per-origin sandbox, but the API could be used outside the sandbox if
> another spec defined a mechanism to grant such access safely.
>
>> 3) read files as they exist on the filesystem (not just a local
>> representation in memory, as currently defined in the File API to my
>> understanding), in bytes and lines
>
> FileReader does this [not sure what you mean about a local
> representation--if you can read an on-disk file, you're doing so via
> memory].
>
>> 4) write files (similar requirement to write directly to the
>> filesystem), in bytes and lines, with overwrite and append options
>
> FileSystem/FileWriter do this [details of appending still being hammered
> out].
>
>> 5) do the above programmatically in Javascript (not dependent just
> upon
>> user selection of an input element and interaction with a file
> selector)
>
> FileSystem does this.  And no, there's no need for the UA to prompt
> the user on each access; permissions should be more on the order of
> "can access temporary filesystem storage" and "can access persistent
> filesystem storage", and need only be granted once.
>
>> 6) provide security for this using the policy-framework approach as
>> being defined for DAP APIs
>
> This remains for DAP to work out.  It should be fairly straightforward
> to add a policy-based mechanism to grant access to FileSystem APIs
> [e.g. your example "documents" folder, via resolveLocalFilesystemURI,
> mentioned elsewhere in this thread].
>
> Thanks,
>
>    Eric
>

Received on Tuesday, 22 June 2010 23:26:55 UTC