Writable file API


Constantly sending notifications to users to remind them of persistent filesystem access would be extremely annoying, and I except most users would simply disable those notifications. However, it could be reasonable to display a notification when the site reopens persistent access.

Restricting the api to certain approved parties would be highly contrary to the open nature of the web.

Requiring users to jump through hoops like going to settings to manage granting folders would be highly inconvenient, and would render the api largely useless.

I’m not sure what you mean by operating systems adding features to grant filesystem access to certain software. Chrome OS already has this in the form of Chrome Apps, and I believe Windows has it for Universal Windows Platform, as well as Android Apps.


the issue here is the responsability of securing access to the file system and folders paths, if you let the developper of the app/site handle it well let’s say they can’t maintain security in every use case, one thing they can do is send notifications to the users for access and push the responsability over to the users it’s annoying but it has to be done, the open nature of the web apps comes with risks and they should know it we musn’t forget that the entire purpose of the api is to provide persistance medium,handling security in the other hand it’s as always complicated


It seems to me that the specification could use an identifier in the head of the document in order to use the features, just as xhtml in ePub books uses an identifier to advertise that it might use custom ePub tags indicating the document structure.

Valid ePub 3 head for a book using structure for assistive readers

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops"
epub:prefix="z3998: http://www.daisy.org/z3998/2012/vocab/structure/"
 lang="en-US" xml:lang="en-US">

An application should require metadata that activates the extra read/write features as menu items in the browser.

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:webapp="http://www.w3.org/2018/webapp"
webapp:prefix="z9999999: http://www.w3.org/z9999999/2018/permissions/fileio/"
 lang="en-US" xml:lang="en-US">

A non-verified browser would ignore the special tags in the webapp scope or could display a dialogue to ask permission to open the page in a compliant safe browser.

Only allow web apps that are strictly XML compliant and that do not include inline <script> elements. Like XHTML, the browser should display an “error on line nnn” message if the page is not compliant with the webapp specification.

Consider specifying an alternative “chrome” (appearance) for web apps, like incognito mode does, to remind the user that the page can read and write files.

Consider W3C accessibility standards. For example, can you access the Open, Save, and Save As... commands with no mouse using a keyboard shortcut or tabbing to a button?

Allow the user to quit the application (CONTROL + Q) even while an alert or menu is showing without having to resort to a system-wide process manager.

Where do the commands appear, in the browser window or in the “File” menu in the browser chrome?


What purpose would the html metadata serve? Why should this require XML compliance? How is this api related to accessibility or to the ability of the user to close the page? What commands would be placed in the browser menu related to this api?


How about a union type filesystem? Web-implemented changes are stored in a filesystem layer that is explicitly unavailable to the underlying OS until manually committed to the local filesystem-- and writes to system directories are forbidden.

Come up with a standard, and a streamlined way of making these optional layers available to other apps (Office, email), and now you’ve got a methodology for securely editing documents without breaking the OS.

I realize this goes beyond the purview of a web API-- In fact, I think this idea could be extended to an OS-agnostic API for document management that could integrate collaboration, synchronization and sharing, as well as web-based editing.

… just a random late night thought. :slight_smile:


How about using something similar to Flatpak portals. Instead of using YES/NO dialogues where the user will just press yes because of muscle memory a File picker dialogue could be presented where the user is shown the available files (could also limit that to Downloads, Documents, etc. directories so that no access to binaries and dll files is possible) and pick the one the web app should have access to. So essentially the web app will only be shown the files the user explicitly gave it access to and it will assume that no other files are present on the system.

EDIT: Link about Flatpak portals (https://blogs.gnome.org/mclasen/2018/07/19/flatpak-a-look-behind-the-portal/)


First thing, to me, would be: only websites with a current, valid and certified digital signature should be able to access this feature. in other words, only reputable websites.

If the digital signature has expired, doesn’t match the exact URL, etc. then no access. Even if reputable. Especially if reputable.


Whitelists across the entire web (mediated by the UA) are simply not workable beyond limited usage; this is part of why Firefox retired the original screensharing whitelist for webrtc as the number of providers and users grew – too much lag, too much investigation per-website required, dealing with revocation and providers going dark (and domains being reused/sold), etc. Permission prompts are a real double-edged sword, as @chaals said


just a thought maybe including the notion of a virtual folder for the edited files that can be opened by the web app and not by the OS, similair to virtual machine harddrive. this virtual folder is like zip file can be encrypted or password protected or accessed by an account session and only the app can open / view and edit this virtual folder . one virtual folder by App or domaine.


Doesn’t that kill much of the utility envisioned here? (and we need to be careful of supercookies, as well) It also then requires worrying about storage management a la LocalStorage (but with the added complication of “you can’t really just delete it”)


I’m not going to get too technical in my reply but I think we do need this API. Such an API would be a godsend to developers and enable a new class of functionality. It’s a natural progression. Security is the problem and so it’s simply a matter of explicit allowance by users. Will some users be tricked? Of course but such a user would just as easily be tricked into downloading an executable.

Today’s web storage is nowhere near what this proposed API. I want it. We need it. Let’s do it.


i see your point ,yes we need such Api (My god ! we need it) , the problem of security is that its vital for the function of the entire system in it self if an expolit is discovered in the API well every App that uses it is also vulnerable to it , at least give the developer a mecanisme to protect the App and allow him to protect the users , not something too fancy that kills the functionality but not too weak to make it dangerous.


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!