The key is the file and folder picker methods (showOpenFilePicker() etc), allowing the web app to interact with existing files and folders on the device. OPFS does not allow that, as it's internal storage in the browser, like IndexedDB.

Browsers have been able to get access to files on disk for longer now than many frontend developers have even had careers—drag and drop was one of the first HTML5 APIs. Same with client-side processing for `<input type="file">` elements. (Directory access through the `webkitdirectory` attribute is another story, but it is supported by all major browsers nowadays—even if it's terribly named and the scary warnings about how it will "probably" go away on MDN haven't been updated.)

As for writing, you don't get unlimited unchecked writes the way that Chrome's proposed Filesystem Access API grants you, but you can trigger "checked" writes (that show a file save dialog) using `<a/>` elements with the `download` attribute. This is arguably a better user experience, because it keeps the user in the loop, allowing them to veto (or rename) the written file at a fine-grained level—which will be difficult or impossible to do if the Chrome team's proposed API because standard.

Overall, the File System Access proposal is a bad one that favors authors over users, and I hope it doesn't become either a de facto or a de jure fixture of the Web platform soon. Here's to hoping for a future post to the Chrome Developers blog announcing that support for yet another experimental API of theirs will be sunset in some future release.

This is not access to the filesystem.

This is access to some controlled contents that happen to come from the filesystem, with interaction explicitly initiated by the user every time. It gives the browser no access to the structure of the filesystem, no way to navigate it, and crucially no way to transparently read or write anything.

This is good isolation, I'd prefer it to be this way. OFS also gives equally good isolation, I'm fine with that.

Sharing between OFS and the rest of the user's file system should be possible, but only explicitly, a la iOS, Android, and the file upload / download dialog.

* * *

Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute, which are not filesystem access.

While Google's new API definitely is.

* * *

What's wrong with <input type="file" /> and the $HOME/Downloads folder?

Why is arbitrary access to a whole folder needed? Cool, yes. Dangerous? Very.

That's how you end up with "March 2023 Report (Final) (Edited) (3).docx".

Making users repeatedly upload and download the same file to work with it is clunky.

> That's how you end up with "March 2023 Report (Final) (Edited) (3).docx".

People having been doing that with Word and other local word processors using (SMB) file shares for decades. There's nothing special about web browsers that's causing it.

People using Word in this manner typically create a new filename only occasionally, not every single time they save. Browsers, on the other hand, will create a new filename every single time a download is initiated. That makes downloads impractical to use as a web app’s sole persistence mechanism; a few smaller web apps do so anyway but it’s rare.

And if they’re not the sole persistence mechanism, if downloads are just an export option separate from a ‘normal’ save, like you see in most web apps, then the 99.9% of users who don’t constantly export all their documents will have to deal with the consequences of the normal persistence mechanism. That is probably cloud storage, with associated centralization, privacy, and cost concerns, though it could also be browser-local temporary storage (cookies / localStorage / IndexedDB / origin-private file system), with reliability and portability concerns.

I'd rather have the inconvenience of clicking the file I want to overwrite than accidentally giving a web-app access to something I didn't intend to. Making mistakes should be hard and intentional.