Writable file API


#21

One thing I’d like to point out about the existing proposal is that preventing “executable” files from being written would make this API useless for many fields of software software development, as .js , .py , .rb , etc are all technically executable files (depending on what interpreters you have installed). An IDE that can’t edit source code files isn’t very useful.

Perhaps the resulting standard could recommend (using language like SHOULD) that implementations block writing to executable file types by default but allow sophisticated users to enable such writes through something like Chromium flags. This mitigates the risk of a naive user clicking through a prompt to enable executable file type writes while empowering sophisticated users to enable them out-of-band.


#22

A possible use case You asked for use cases. Here is mine. I made a little PWA https://io.benfrain.com - its a little app for choosing people from a roster for organising soccer games and the like.

Anyway, as the user creates their roster I save this in localStorage and give the user a way to back up that data as a JSON file. However, this is dependent upon the user actually backing the data up. If they haven’t and clear their browser cache they have to start all over again next time they open the app.

This would give me the possibility of having a default file created/authorised on initial start-up for the app e.g. ~/user/webapps/io/backup.json which could then be used to more permanently save the data on the PWA and update as needed.


#23

Possible Use Case: A podcast (or similar app) that wants to allow users to download podcasts to be able to use offline.\

I’d like to allow the user to select a Downloads directory for the app and authorize the app to use it. At that point the app could add files and refer to them from the src attribute in the audio element as needed.


#24

I would also like to be allowed to save out whole directories of content. Like having an online unzip utility. Or when saving out a web page, you need to save the html and also a directory with additional images and stuff. Ditto with certain 3d file formats. Being able to read and edit whole directories would also be nice, but that’s more dangerous from a security perspective, so that probably wouldn’t work. But being able to create a new directory and write multiple files to it seems like it could be done safely.


#25

Use case: a journaling app that lets the user choose a folder — preferably inside whatever cloud drive service they use (iCloud Drive, Dropbox, etc.) — where the app saves their journal entries as plaintext files. The idea is these entries can then be accessed using not only the app, but also any text editor on any platform. The result is an offline-first app that also syncs the user’s private data across their devices without having to go through a server controlled by the app’s developer.

I’ve been looking and waiting for an API that would allow applications like this. This one seems to be the closest.

The ideal API for this use case would basically be the equivalent of ”iCloud Drive for the web”, but here’s a workflow example:

  1. User starts writing their first journal entry.
  2. User is prompted to select/create a folder on their drive.
  3. If allowed, the app will from now on save and auto-name any journal entries into the chosen folder, possibly grouping them into sub-folders as well.
  4. When the user wants to browse their journal entries later, the app should be able to fetch whatever plaintext files are in the folder and read them.

I’m guessing this API won’t quite be able to do everything my use case requires, but I’d consider building the app even if it ended up being roughly 50% lousier to use than my example above. :slight_smile:


#26

Security Model Ideas

  1. Similar to two-factor authentication, users could confirm or renew access to local folders/files from other devices.
  2. Reminder notifications of folder/file access granted could be provided to users via emails, device notifications, when opening the browser, or at certain frequencies when the browser stays open over a few days. (A similar feature exists in Gmail when automatic forwarding filters are configured).
  3. Audit trails of folder/file access granted and read/write to those folders could be visible to users.
  4. Web apps (or developers) would need to be vetted/authorized/validated before being allowed to request folder access.
  5. Folder Authorization by Users
    1. Users could explicitly pre-authorize read/write access to folders in browser settings, prompting users for OS-level passwords when doing so. Web apps could then detect authorized folders or instruct users on how to add folders for their specific browser.
    2. OS vendors (Chrome OS, Mac, Windows) could add features to grant file system privileges to certain apps like web browsers.

#27

Use Case: Music Library Encoder & Player

The Opus audio codec is a modern replacement for MP3 and AAC audio/music files, and it would be great to have access to local devices and folders for encoding and playing our music libraries. Streaming, byte-level access to CD/DVD devices and other external devices would also help.

A web app with local folder access could serve as an open-source replacement for the restrictions and limitations imposed by iTunes, Spotify, and other music services. I’d like to work on this and would currently need Electron to achieve local folder access. This use case also applies to movie libraries.


#28

I find it hard to believe many sites will be asking users for the ability to write to files without apparent reason

@DanielHerr I agree. Perhaps maintaining an approved whitelist of apps/domains could make developers work for this privilege and hold them accountable.


#29

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.


#30

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


#31

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?


#32

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?


#33

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:


#34

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/)


#35

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.


#36

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


#37

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.


#38

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”)


#39

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.


#40

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.