Writable file API


Writable files

https://github.com/drufball/writable-files/ explores solutions to this problem.


Today, if a web site wants to create experiences involving local files (document editor, image compressor, etc.) they are at a disadvantage to native apps. A web site must ask the user to reopen a file every time they want to edit it. After opening, the site can only save changes by re downloading the file to the Downloads folder. A native app, by comparison, can maintain a most recently used list, auto save, and save files anywhere the user wants.

Use cases

  • Open local file to read
  • Open local file to edit and then save
  • Open local file to edit with auto save
  • Create and save a new file
  • Delete an existing file
  • Read meta data about files


  • FileSaver.js polyfills saveAs() from the [W3C File API], but files open in a new window instead of downloading on Safari 6.1+ and iOS.
  • In Edge, Firefox, and Chrome developers can:
    • Create a fake anchor element
    • Set the download attribute to the desired filename
    • Set href: to a data URI
    • Faking a click on the anchor element
  • Setting window.location to 'data:application/octet-stream' + data_stream
  • Hidden Flash controls to display a “save as” dialog

These methods are clunky and only support “save as”. They do not support most recently used lists, auto save, save, or deleting a file.


It’d be nice to be able to request the user pick a file for editing, and that the file can be maintained open for reading and writing. It would be similar to what apps for Google Docs can do with documents in Drive, but on the local machine instead of in the cloud.


How does this proposal compare with https://w3c.github.io/filesystem-api/? The use cases seem similar.


That link says

agents are responsible for allocating space for the creation of a sandboxed file system and for imposing storage quotas on that virtual file system

It seems the difference in mine is that we’d be accessing actual files anywhere in the user’s file system, as allowed by the user, not in a virtual file system that is sandboxed in the browser.


Yes, but that use case has been looked at often, is known to be one of the features that would be very useful, and has had several proposals fora way to do it as part of the work item, dating back most of a decade.

It’s also one that worries security people a lot in particular, which is one reason it hasn’t made it to an accepted standard yet, I think.


That’s probably the reason, and it’s a lame one. I bet the first implementation would be more secure than what most average non-tech people get out of just having Windows (f.e. click here, download screensaver, boom, virus galore).

Android already let’s apps do this; android apps can access files limited to a specific folder by default. I’m sure it’s not difficult to let Chromium do it, but Google probably hasn’t prioritized it.


What trusktr says is right - the FileSystem API is about sandboxed files owned by the browser. This proposal is meant to provide access to files on the device. We’ve run the proposal by some security folks here on the Chromium team and they think the model proposed should work.

The basic idea is that sites would only have access to files/directories that the user explicitly opened. Further, if the file changed outside of the site, it would need to reacquire the permission. User agents could decide whether they want to automatically grant any of these permissions or to show the user a permission dialog every time.


@dknox Exactly! And, the user could tell the browser to remember the permission. Or, the browser could raise a prompt like “File XXX was modified externally, reload?” or similar.


I agree that it is possible to deal with the security issues, and I really would like the functionality - when Opera had it, I could do lots of really useful stuff, albeit only for Opera users.

Yes, it needs to be restricted to files the user explicitly named. Allowing the app to suggest filenames like autorun.inf or .bashrc, to put files in dodgy places, or look for someone’s inbox, are the sort of phishing attacks that concern people who have looked at this. There’s also a supercookie-type fingerprinting vector, but I’m not sure that’s new and there are easier ways to do the same thing.

In reality I think a lot of this comes down to getting the security right in the UI - which means presenting risky actions to users in ways where they understand the risk. We are better at this than we were a decade ago, but we also understand the risks much better and I think that too makes us more cautious, as an industry.

The fact that native app platforms allow things that frighten the security daylights out of me doesn’t seem like a good reason for doing the same thing on the Web. But as I said, the functionality is very valuable, so I hope we can figure out a secure enough way to make it available that browsers do this.


A permission prompt like “Allow this site to write to files and folders you open with it?” would be sufficient.


Probably not.

In theory, it should be fine, but in practice permission prompts train people to click “yes” to everything, whether that is reasonable or not. Given the almost insatiable desire of the Web for tracking mechanisms, and the fact that any such permission given by the user could be reasonably argue to have been consent to recording information on the user’s machine in the same way as the EU now insists people do for cookies, it’s not unlikely that so many sites will ask for this permission that it becomes as meaningless as the fine print on a contract. Which leads to people clicking to agree to it without ever having read it - even if they have to scroll down pages of stuff before they are allowed to click. For example did you read this sentence? There is quite a lot of practical research on this, and it’s pretty clear that permission dialogs do not amount to getting informed consent for any interpretation of the term that assumes the person knows what they actually agreed to.

Further, there are parts of the file tree that are far more sensitive than others. It’s one thing to ask permission to read mbox files for an email application, another to read and write files that typically contain password information - even hashed, because given time those hashes are insecure - or set user preferences in ways that can be exploited for identity theft or the like.

That said, I don’t think people have come up with a very clear better answer, so the issue is about how to make sure the question asked is as focused as possible and the user gets as clear as possible a message that they should be thinking hard before offering this permission, or that it should be tightly circumscribed and relatively annoying to get into things that are sensitive.


I find it hard to believe many sites will be asking users for the ability to write to files without apparent reason, and even if they do, they cannot do anything unless the user chooses a file. It seems like you are implying a way to arbitrarily access any files on the user’s computer.

Writable File API - status?
Writable File API - status?

Currently, the proposal suggests that we may allow some method to save a new file to the device, which might allow the kind of tracking that @chaals mentions. @DanielHerr makes a good point that most of the other use cases would already require a specific user action. So maybe if we only showed a permission prompt to save a file that the user hadn’t already explicitly chosen?