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:
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.
<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?
- Suggest alternative applications
- Notify of insecure applications
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.
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
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.
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.
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.