Browser, mount that folder, thank You!
These are the stuff every guy, who has pocked the browser or the client-side lately, would like to hear about. Behold the File I/O the W3C spec for local file access.
Here is a description of what it does. The interesting part from the text bellow is outlined in bold:
Traditionally, web applications have had little to no access to resources residing on the local filesystem. The ECMAScript interfaces for file I/O specifies a sandboxed file system, where a widget or other trusted component can gain access to the local file system.
The File I/O interfaces in this specification represent an abstract filesystem, without knowledge of the underlying filesystem’s path separators, conventions for setting file properties such as read/write permissions.
The interfaces provide methods for opening files, writing to them, creating files and directories, moving or deleting them, and so forth.
In order to work with files, an application first has to acquire a mountpoint. A mountpoint is either a reference to a file or folder on a disk, or an abstract reference to a set of files which might not necessarily be within the same folder.
I wonder which folder the typical user will select. Hmmm, the Desktop
, My Documents
? And where all these interesting files are? Mac OS X user, you’ve got a problem. Don’t mount the desktop. Just don’t!
comments
I think this API really has to be integrated into an OS itself. e.g a default designated directory which can’t make remote api calls to other parts of the system.
I don’t think the web browser is ready for this yet. Even though I think this would make offline email a dream.
I think that any work on this API should be terminated. It is not cool :) I can easily see how it will be abused.
I think on the first page they sum it up best. “There are several known issues in this specification” though they go on to mention issues not at all related to malicious people abusing it.
Hi, I wrote the initial version of that input, and I’d like to give a few insights in to where it is being used, and some of the constraints given
First, the security constraints that are currently in the proposal are meant for use in applications you have already chosen to install on a system (e.g. widgets), “Web applications” the current proposal is explicitly _not_ about your average application served directly over HTTP(S).
Secondly, it’s worth noting that the API, as is now, does little you can’t do with equivalent APIs in Firefox extensions, Dashboard widgets or Windows Vista sidebar gadgets, except adding sandboxing and required two-step user interaction before allowing access.
So, your corrected headline should read “Locally installed Application installed from a trusted repository, query the user for access to a folder of the user’s choice”
The API as proposed seems ok for things like Widgets, but totally unsafe for content served over the Web. We would certainly not implement it in Safari for Web content as currently proposed.