Re: file-system-api: filename restrictions

On Tue, Jan 11, 2011 at 5:33 PM, Eric Uhrhane <ericu@google.com> wrote:
> 2) Developers often don't read UA logs.  We should fail early on the
> dev box, rather than failing later on the user's machine.

(I guess I just lack sympathy for developers who completely ignore
browser warnings.)

>> - existing filenames that differ only by case.  Similarly, should the
>> UA just ignore all but one of them and make a log to the console?
>
> There's no problem accessing those through directory enumeration, or
> via a supplied path.  You just can't create this situation using the
> API.

It could happen if the user's locale changes, but that's not a likely problem.

The infamous Turkish "I" comes to mind as a portability problem: code
could reasonably create "Info" in one place and read it as "info" in
another, which would be different files in a Turkish locale.  Windows
still treats "I" and "i" as the same letter even in Turkish codepages,
but a Linux glibc-based implementation wouldn't.

Should the usual equivalences for the ASCII range be required,
regardless of the user's locale?

> However, an obvious expansion of this API which we've talked a lot
> about is the ability to expose other "mount points" to the browser.
> For example, a trusted app might be granted access to "My Photos" or
> another similar directory.  There the majority of the files are
> expected to be created by apps outside of the browser, and you run
> into the thumbnail problem you describe above, where a
> read-modify-write of a path or even a copy operation can inadvertently
> create a file path that's banned by the API, but is legal on the host
> system.
>
> In a perfect world, I think we'd want all paths that came from the web
> app to be LCD-safe, but all paths that came from the host machine to
> be permitted.  Since that's not generally detectable by the UA, or
> even well-defined in all cases, perhaps we can help developers to
> solve the problem manually.  We could offer another API [or just a
> flag in the existing APIs] that says "I'm using paths derived from the
> local system.  Let me try this, even if it's not LCD-safe]."  I don't
> think we want to allow that in the per-origin sandbox defined in the
> current spec, but I could see it being quite valuable for other mount
> points.  If that sounds reasonable, we can put that in when we spec
> this potential future API expansion.

Letting the user grant access to specific directories is in my opinion
the one big missing piece that will make this API very interesting.
That's also when this will all become much more important, so leaving
these to be addressed together seems fine.

-- 
Glenn Maynard

Received on Wednesday, 12 January 2011 01:02:38 UTC