I for one want nothing to do with this. File system access is for good actors only, and the advertising assholes have poisoned the well for a web browser being anything other than a dumb document browser with the privacy settings turned up to the max for me.
A neutral file system and standardized file formats are a huge part of what has made computing able to do interesting things in the past 40 years. The fact that one application can output a file, and another can open it and operate on it is basically at the core of the unix philosophy, and the reason we can have things like developer workflows.
If I, as an application author, can only work on data in ways that are intended and officially blessed by another application, we basically have the situation we have on mobile where everything is siloed, and the state of the art is limited by the imagination individual application developers.
How then are web apps supposed to become part of a more durable workflow (i.e. opening/saving/moving/backing up files) if we do not permit them the same privileges as native apps? I don't think web apps should have total control over your filesystem, but why not at least allow them to operate within a folder?
They aren't. Web apps can't be trusted with access to barely anything on your system, lest they copy it to sell as advertising. As long as the internet is fueled by advertising, essentially all web apps are adware.
BTW both Safari and Firefox are not going to implement the File Access non-standards that Chrome pushes. They expose too much, there are no good ways to limit the exposure etc.
When you think about it, the modern internet resembles a welfare state. Everyone's day to day sustenance is sponsored by a few wealthy benefactors, meanwhile they essentially hoover up what remaining potentials there is. There could be so much more than what we think is possible now.
That can be a better idea. (Unfortunately the HTML file input in any web browser that I have tried does not allow the user to change the file name to a different name than the local file name. This ought to be fixed.)
When it asks the user for a file, can also specify the wanted access: read, write, read+seek, or read+write+seek. Requested format can also be specified, but the user should be allowed to ignore the requested format if wanted and instead specify an arbitrary file. For writes, estimated file size can also be specified as a hint, which can also be ignored. Then the user can type in a file name, or for the non-seeking modes, a pipe is also possible. For write non-seeking, the user can specify append or overwrite. For seekable files, a pipe is not valid. For writing to files, the user can also optionally specify the maximum size that the file is allowed to have.
That's basically what file system access is like in Android, unless you give an app Storage permission. Seems sandboxed enough if no other web apps can view it.
