I am a real person and I don't want this.
This whole idea is stupid. Another C program with and ability to run arbitrary code off the network written by idiots and nasty folk being given arbitrary filesystem access. Have we learned nothing? We need more controls (MAC / process sandboxing) not less.
Just because someone wants to do something to make their lives easier and asks a set of people what they want who says yes doesn't mean it's a good idea.
I say this as someone who has written desktop/web integration stuff over the years without this.
Only on Hacker News would “we offered users the ability to save to disk and 65% used it” be seen as a sinister conspiracy theory.
The percentages of users who use or don't use specific features, in isolation, cannot be effectively used to determine those users' opinions on the relative merits of those features. There are so many other factors at play that you really need to do some kind of explicit survey to determine whether, just as a for instance, some of those 65% would prefer a different way of saving files but don't have the choice (or think they don't), and, conversely, whether some of those 35% would be happy to use that feature, but don't know about it.
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, giving them the opportunity to veto (or rename/relocate) the written file—which will be difficult or impossible to do if the Chrome team's proposed API became standard.
Overall, the File System Access proposal is a bad one that gets the developer vs user prioritization wrong (favoring the convenience and satisfaction of the former over preserving control for the latter), 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 this is yet another experimental API of theirs that they have decided is going to be sunset in some future release.
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.
> This is not access to the filesystem.
Wrong. I know what "this" is, thanks, and it is access to the filesystem. That's because "this" here—in the subthread you have just posted to—refers to Chrome's experimental implementation of the larger proposal (which is literally called "File System Access API"), not the limited subset described by the submission as having just gotten enabed in Firefox.
While Google's new API definitely is.
It's the `download` attribute, but yeah, I understand the significance of those words. I wrote them.
Your replies in this thread, on the other hand, are confusing at best. What are you actually trying to communicate?
Why is arbitrary access to a whole folder needed? Cool, yes. Dangerous? Very.
Making users repeatedly upload and download the same file to work with it is clunky.
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.
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'm insufficiently informed about the differences between File System Access API and Origin Private File Access to have an opinion on which of those I think is a better choice, but please remember that Your Experiences Are Not Universal.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
....what?! ... World Wide Web Desktop? World Wide Web on my desktop? My desktop on the World Wide Web? There must be some confusion here. : )
If an app becomes desktop app why the heck using a browser?