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.

I think a FS api would be good for importing/exporting unzipped folders, perhaps from an IDE or other program. In addition to writing files, directory manipulation would be nice.

So the code would make a request to a file/folder, maybe giving a regex to help determine the path, as well as acceptable file/folder extensions. The user is than shown a quick disclaimer before the file chooser. The chosen file/folder is than mounted to a virtual directory without any metadata (e.g. original path), and a boolean is returned representing if the action was canceled. The program now has full access to this virtual directory, excluding symbolic links. However, all file usage is logged. The user can choose to revert… or more likely commit… any changed files, and optionally send statistics on file names to their browser’s developers (e.g. Google, Mozilla).

Perhaps you can also exclude files from being written/read?

I would love a way to read/write files in a single directory (chosen by the user), even if it was a feature restricted to PWAs (installed web apps).

And it would be nice if one way of interacting with it was dragging & dropping files/folders onto the page. Drop a folder and then be prompted to give the webpage permission to use the folder.

I work on the Chrome Remote Desktop team. Our use case involves saving files and directories that the user has selected to download from a remote machine, transferred via WebRTC.

For files this means we want to trigger the browser to prompt the user for a save location (or possibly pick a default based on the user’s download settings), and obtain a handle to write to only that file as data is received. Once the handle is closed, we’d have no more access to the file.

For directories, we’d similar want the user to pick a location and name (with a default provided) for a new directory to be created. The website would then have access to that directory until the handle (or page) was closed.

Ideally, if the download was aborted (including by closing the page mid-transfer) the partially written file/directory could be cleaned up automatically. It might also be nice if the browser appended a .part extension or similar while the file/directory is still being written, similar no a normal download.

Since this would not provide any persistent access or access to existing data, it seems like it should be safe for use by standard websites such as ours.

1 Like

Same here. I’m in charge of a small org building PWAs, and this is on our “wishlist” of web platform features (along with things like unfettered network access). For example, we could build a music player PWA, in which the user can select a directory. The music player would then get future access to the directory without needing to request permission every single time.

This would be nice for Instant.io to share files larger than RAM.

Definitely! I can think of a lot of use cases for this. It appears that the Chrome people are actually running an origin trial - https://web.dev/native-file-system/

I would love a way to read/write files in a single directory (chosen by the user)

I’d also like to see a feature like this implemented. I’m developing an application which uses WebRTC to connect peers directly for chat and other data synchronization features. I want to be able to share and persist images without requiring a central upload server and links.

It’s simple to send and receive data over a WebRTC connection, but storage options are limited to localStorage and IndexedDB which don’t seem like the best option for blob storage. Files are also more user friendly for inspection. Getting a user to export data from localStorage/IDB would likely require a custom explorer which relies on URL.createObjectURL.

The current requirement of prompting the user for each new file saved hinders a good UX for apps. Something like localStorage’s expanding quota limit would be nice for the native file system API.

Does this apply to usb memory sticks, usb storage devices etc? If so it would be good to give the user the option to only allow access to usb devices etc. The reason is I have a program that currently uses localStorage for public/private keys etc and I would like to give the user the option to store/communicate these keys from his usb device. I don’t need access to the whole file system, only connected devices through usb.

Terrific! Finally a solution for a standalone simple html javascript app. I’ve been waiting for this a long time. html and javascript is so easy for prototyping and being able to save a file was the final piece of the puzzle. I will be creating office tools for a small group of users.

Use case:

I have a Chrome app that can record streaming contents from various websites. It works by downloading fragments (typically HLS or HDS) and saving and appending the file to the local filesystem.

The app heavily relies on the excellent chrome.fileSystem API to get a handle to a directory chosen by the user in which it can add and modify files.

(This use case is similar to adamzr’s podcast app)

Some thoughts of the implementation:

In chrome.fileSystem only file or directory operations initiated by the user are allowed. Thus, it is not possible for a Chrome app to suddenly write to a certain directory without asking for permission. It can’t even suggest a directory (except the previously chosen).

As I see it, there is really no reason why a native file API should be much different than chrome.fileSystem. Everyone can install a Chrome app in three seconds and thus grant access to their filesystem with all the advantages and risks it can introduce. And as others have pointed out, such a permission is really not more dangerous than downloading some native app (or executable) which can in fact potentially do much more harm.

Another approach for many developers who want to make a native app using html + javascript is frameworks like Electron and NWJS which uses an embedded Chromium. These apps can also access the local filesystem (a stellar example is VS Code) and as such are potentially a security risk. We have to accept that power and risk go hand in hand and every time an app can do anything locally except of just showing stuff in the browser, we also have a potential risk.

What is important is that the file access is not given ad libitum to the user’s system and that the user is properly warned when installing, and - to a lesser degree - when using the web app. And as such, it is important that the user truly understands that they are in fact installing an app and not just using a website.

Now when Google finally has come up with a EOL of Chrome apps I really hope this writable file API will be implemented fairly soon.

My use case is an app that monitors a directory on the local disk, recognizes when a file has been added. And based on that, copies that file to another directory. This is done by having the user select a source and a target folder, obtaining full permissions on both of those and then monitoring every 5 seconds if a file is added to source.

I had this implemented in pure Python, this required an install on the users computer. I now have it implemented in JavaScript and a tad of HTML/CSS. It works like a charm actually.

There is just one isue, mostly in the realm of usability;

It is not possible to save permissions between reloads. If the user closes the tab or reloads the page or does any action equivalent to that. Ie, click on an internal link, both permissions and the location of Source and Target are lost.

There is currently no way to save either the handle, or the relative filepath. Meaning, that every time it is lost, the user needs to be prompted to give those again. This is of course a hassle.

Some of this can be overcome by limiting reloads, trying to use Ajax to keep the page up to date. However, my users are the kind that reload a lot. Persistence is the main thing missing from this to make this usuable.