Writable file API


Sure. Well, the browser is already able to sandbox the filesystem. This would (In a way) expand web storage to include the rest of the filesystem by explicit whitelist. I think the best way would be a dialog to the user like this…


Example.com would like to access the following directories/folders (And their contents) on your hard drive:


If you allow this, example.com will have full, unrestricted access to create, delete and modify the files in these directories. Do you want to grant example.com this filesystem access?

      [No]   [Yes]


Thank you for your interest.

What purpose would the html metadata serve?

The XHTML metadata defines a strict vocabulary that a web page or application can use. For example, early web pages used special tags that were only usable with some browsers. <CENTER> and <FONT> are some examples of tags that modern browsers do not understand. The xmlns:webapp="http://www.w3.org/2018/webapp" webapp:prefix="z9999999: http://www.w3.org/z9999999/2018/permissions/fileio/" portion defines additional tags that would be reserved for web applications that are not in the current W3C XHTML specification. This would allow the working group to define tags and behaviours that standard web pages do not require.

Why should this require XML compliance?

This is a requirement for controlling the vocabulary and behaviour of the web rendition engine. In addition,

  • XML is specifically designed for simple and unambiguous machine interpretation of code.
  • XML validity is easy to verify.
  • Using strict XHTML reduces the possibility that different web browsers will interpret the markup differently or in an unexpected manner.

How is this api related to accessibility or to the ability of the user to close the page?

W3C describes the goals of Accessibility as follows:

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

  • Historically, many flash based web-applications have not been easy to use for people who have limited sight or the ability to click accurately on a button or menu item.
  • Some modern web applications work better. For example, using Google docs, you can hold the ALT key and tap the F key, then hit the DOWN ARROW key to select a file function.
  • When the W3C creates a new standard, there is an opportunity to codify accessibility into the new standards in an integrated and thoughtful way.
  • Users who have limited motor abilities or are using a platform that does not have a non-modal “Quit Program” command easily available find it difficult to close a malevolent or poorly implemented program running in the browser.


I’d like to call this out as a good idea, with a slight streamlining: put the file count next to the confirmation button, and don’t let the user confirm access until you’re done counting. This will prevent the foot-gun of "give the website access to C:\Windows" by taking several seconds to count up to a really big number before letting them accept it, while making relatively benign access (newly created empty folder) easy.

This seems kind of hokey - if you wanted to trick someone into executing code, wouldn’t you just use an <a download> instead of making them navigate to the directory you’re dropping your stuff in?



That isn’t really the threat model I envisioned. Using the Writable File API to overwrite an existing executable, particularly one that is configured to be executed in an elevated context like a Windows Service executable path, is what I’m concerned about.



I love this, hope it will work out. A thing that I would also really like, is that a web app can be allowed to get access to a file across sessions (maybe with a prompt for security). This would be for example useful in an app that can open “Recent Files”



Another thing that would be great, is a web app can suggest a filepath for the user to open, so that the user doesn’t manually need to navigate to the file, that can also be accomplished with a file open dialog with path+filename already filled out. Very useful if a file contains a link to another file. I realize that this can more easily trick users maybe? a more restricted solution to this is to only be able to do this with files in same folder as origin file, or a relative path to origin file



Would this allow for read-only access (including file metadata) to a “Program Files” directory?

Use cases:

  • Suggest alternative applications
  • Notify of insecure applications
  • etc.


In my case I create graphics applications, all of these contemplate the use of multiple local files.

In the case of janvas (SVG editor), I am currently forced to include the images that the user chooses from his HD within the SVG document. So doing the documents can become quite large, as in the case of creating a photo book with all the images, difficult to save remotely at each change. It would be interesting to link the images rather than to include them. Before I used a chrome app and api filesystem that allowed files selection in “retained” mode, then these Chrome APPs were deleted outside Chrome OS.

Furthermore, the use of local files frees us, small developers and small businesses, from keeping the files of our users remotely, thus freeing us from the onerous management and responsibility of user files. This was partly solved with Google Drive, but that’s not enough.

I believe that the possibility to save and read files will opening a new chapter for the web.

We need these APIs!



Suppose you want to write a PWA that is a local File Manager. Without full access to the local file system these kind of PWAs can never be done, and why should it be this way? We are all already well used to answer questions like “This app wants to access your contacts… your photos… your this and that… and so on” from native apps installations. Why could not be just the exact user experience when installing a PWA? Just ask the first time permission to the user like you do with native apps and if he is ok let the PWA access every local file. What could be wrong with this approach? I dream of a day where users do not even notice if it’s a PWA or a native app.