11 ms·

I, on the other hand, am actually annoyed that Mozilla doesn't support the File System Access API. I understand that there are security concerns that need to be

by ar9av 4y ago

I, on the other hand, am actually annoyed that Mozilla doesn't support the File System Access API. I understand that there are security concerns that need to be evaluated more, but the API has to explicitly request for user permissions anyways and has to re-request user permissions when the tab is closed. I'd much rather live in a world where I can briefly use a web app to do some task than be forced to install a myriad of native desktop apps that have unsandboxed and unpermissioned access to everything on my system. Origin private file system access seems cool, albeit a half measure. Seems like a better alternative than putting blobs into IndexedDB.

domh 4y ago
Yeah this is my take too. I generally appreciate and support Mozilla, but this time I feel like they're on the wrong side. If I can use a webapp that persists a file to my filesystem, it means I can have a local backup without having to make an account for a site.
- eshnil 4y ago
  Saving a file is easily implementable without a Filesystem access API. See https://draw.io/ https://draw.io/ as an example.
  - esperent 4y ago
    Draw.io's local file saving is clunky as hell and I'm sure even that was an absolute pain for them to get working.
    - eshnil 4y ago
      I actually implemented it recently in one of my open-source apps. It's 6 lines of Javascript: Create an <a> element, set the data in its href with: element.setAttribute("href","data:text/plain;charset=utf-8," +encodeURIComponent(content)) and element.click() followed by document.body.removeChild(element); This works perfectly fine for saving single files. FileSystem access API is useful when entire directory needs to be stored and perhaps without the standard SaveAs.. UI.
      - c-hendricks 4y ago
        Those users probably didn't need their RAM anyways
- apatheticonion 4y ago
  As a web developer I tried really hard to make an offline-only "progressive" web application. It was a web-based clone of the "Strong" Android app - a simple fitness tracker that is basically an excel spreadsheet. I made for myself with no intentions of commercialising. I stored all the records in IndexedDB but really wanted to persist them to the fs as a file. I was hoping to sync workouts at the user's discretion - put the "workouts" file on you Google Drive or whatever and just load it using the app when you use it. It wasn't possible, best I could do was a manual import/export. Worst part was, a few months after I made the app, Chrome dropped a bug on an update that wiped local storage on update, so I lost months of IndexedDB records. I now look at apps like Google Sheets and Google Docs with disdain. Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers). Combine FS access with using WASM as a compile target, suddenly you're writing native cross platform applications in C++, Rust or your language of choice - if WASM ever gets off the drawing board. I feel like the web is an analogy for Fusion, the good part is always a decade away. /rant
  - madeofpalk 4y ago
    If we're calling C++/Rust to WASM in the browser "native", then Javascript is native also.
  - sgbeal 4y ago
    > Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers). And files which other folks can generate, like marketing malware injected there by out-of-browser applications and/or shady OS vendors (who might pre-populate data for their own sites, as well as business partners' sites (for a fee, of course), under the pretense of "improving user experience"). If browser-accessible storage is accessible to arbitrary out-of-browser applications, arbitrary package updates and installers can _put stuff there_ or overwrite stuff which is already there. We can be certain that such things would rarely, if ever, be to users' benefit.
    - apatheticonion 4y ago
AshleysBrain 4y ago
I agree - the File System Access API with full integration with local files and folders is essential for desktop web apps. Ours[1] supports File System Access for saving and opening projects in Chromium-based browsers, and our stats show a full 65% of users save that way. So it's also what real people actually want to use in browsers. [1] https://www.construct.net https://www.construct.net
- tgv 4y ago
  I'm basically against the browser getting too much access, so what is missing in Firefox 111 for your use case? Is it just less convenient for end-users?
  - AshleysBrain 4y ago
    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.
    - cxr 4y ago
      Browsers have been able to get access to files on disk for longer now than many Web 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 did eventually gain support from all major browsers—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, 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.
illiarian 4y ago
> but the API has to explicitly request for user permissions anyways You mean, just like all other 200 [1] or so APIs that want to request that access? It's a good thing some browser vendors don't look at these APIs in isolation, but look at the whole picture. So they see all the other APIs that also want to spring a pop up requesting access to something, and are concerned about confirmation fatigue. [1] Exaggeration. Or maybe not. These days between all the hardware APIs chrome is pushing, and existing APIs like notifications and locations, and half-consensus APIs like file system access and MIDI there might be more than 200 hundred already.
- deleted 4y ago
  [deleted]
- capableweb 4y ago
  Seems there are about 18 APIs that require explicit user permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API https://developer.mozilla.org/en-US/docs/Web/API/Permissions... 7 of those are actually available in Firefox at all.
  - illiarian 4y ago
    It's definitely more complex than that because many of those APIs have additional areas that may or may not be covered by permissions. For example, Firefox implemented permissions for enumerating MIDI devices, and Chrome didn't, with predictable results: https://twitter.com/denschub/status/1582730985778556931?s=20 https://twitter.com/denschub/status/1582730985778556931?s=20
- AshleysBrain 4y ago
  Arguably looking at the whole picture means recognizing that some of these use cases will instead be done by traditional desktop apps that have far more invasive access often without needing to prompt the user for permission at all. In my view web browsers are a more secure and privacy-preserving option than that.
  - 4y ago
BlueTemplar 4y ago
If your app is complex enough to need something like this, you probably should make it native anyway (the browser interface is going to get in the way). Don't try to turn the browser into an OS ! (I probably shouldn't give any support to Windows by even mentioning it, but doesn't it have built-in sandboxing and especially permissions too these days ? What else the "run as an admin" command is about ??)
- afavour 4y ago
  > If your app is complex enough to need something like this, you probably should make it native anyway Are we really still making this argument in an era where Figma and Google Docs exist?
  - norman784 4y ago
    Don't they save the files on the cloud? I think this is about having access to local file system.
    - afavour 4y ago
      My point isn’t about local file system access. OP said that if you’re making a complex app it should be native. I was pointing out that millions of people use complex webapps every day, adding file system access is a logical attempt to meet an audience where it is.
      - BlueTemplar 4y ago
        I'm not blaming Mozilla here (at least I don't think I should..? Not sure that the «enabler of bad behaviour» argument can really apply here ??)
    - Steltek 4y ago
      I wish it wasn't a local filesystem. Google Docs was superior (for me) in that my files were available on every device. To achieve that here would require setting up Dropbox or similar and dealing with edge cases. If this API was more sophisticated with conflict resolution, Firefox could sync these files for me (maybe S3 compatible? I dunno) and then every app could have magical Dropbox/GDrive capabilities instead of a boring old tech folder that gets wiped out every so often.
reportgunner 4y ago
> I'd much rather live in a world where I can briefly use a web app to do some task than be forced to install a myriad of native desktop apps that have unsandboxed and unpermissioned access to everything on my system. I just use a vanilla install of chromium for this.
pjmlp 4y ago
Unfortunely it harldy matters anymore if they implement something or not. On all our projects it is already downgraded to "nice to have" status, if it matters at all.
mihaaly 4y ago
I wonder if the argument is here then to make the browsers as secure as a desktop app by giving them all the possibilities of a desktop app? Giving web and desktop apps the same access - temporarily or permanently alike, no difference - to local data and system will make both the same secure. Or the web one being even less secure as that is inherently remote centered while the desktop could be restricted to local. Ultimately nothing is secure with a non-paranoic user nowadays so idealisticly no reason not allowing the same access to a web app. But oh there is! Knowing that one does not need to worry at least about a surely web app digging around in the local system above desktop apps that may or may not send local data somewhere is better. Should mitigate the risks not aggravate! Btw. desktop apps has no unpermissioned access to everything on your system.
kitsunesoba 4y ago
For what it’s worth, mac apps have had disk access permission prompts (along with prompts for several other permissions) for a while now. Its permission system isn’t perfect, but it’s a far cry from unpermissioned access. Windows and Linux do have a way to go in this regard, though. I’ve seen efforts from the Elementary OS team to include some form of permissions in their distro but I’ve not seen it elsewhere in desktop OSes aside from macOS.
- vetinari 4y ago
  > but I’ve not seen it elsewhere in desktop OSes aside from macOS. Flatpack-ed applications on Linux do have similar sandbox.
  - c-hendricks 4y ago
    Windows does as well. But like Flatpak, I think they're handled at install time, not at-access time.
nullfield 4y ago
I don’t like OPFS much more; almost less, in fact. “It is not intended that the contents be easily user-accessible” is different from “it is intended that the contents not be easily user-accessible”, and they sure seem to be trying for the latter when they don’t need to, especially given that we know it’ll be a short matter of time until OPFS is being abused in some way.

by ar9av 4y ago

domh 4y ago

Yeah this is my take too. I generally appreciate and support Mozilla, but this time I feel like they're on the wrong side. If I can use a webapp that persists a file to my filesystem, it means I can have a local backup without having to make an account for a site.

eshnil 4y ago
Saving a file is easily implementable without a Filesystem access API. See https://draw.io/ https://draw.io/ as an example.
- esperent 4y ago
  Draw.io's local file saving is clunky as hell and I'm sure even that was an absolute pain for them to get working.
  - eshnil 4y ago
    I actually implemented it recently in one of my open-source apps. It's 6 lines of Javascript: Create an <a> element, set the data in its href with: element.setAttribute("href","data:text/plain;charset=utf-8," +encodeURIComponent(content)) and element.click() followed by document.body.removeChild(element); This works perfectly fine for saving single files. FileSystem access API is useful when entire directory needs to be stored and perhaps without the standard SaveAs.. UI.
    - c-hendricks 4y ago
      Those users probably didn't need their RAM anyways
apatheticonion 4y ago
As a web developer I tried really hard to make an offline-only "progressive" web application. It was a web-based clone of the "Strong" Android app - a simple fitness tracker that is basically an excel spreadsheet. I made for myself with no intentions of commercialising. I stored all the records in IndexedDB but really wanted to persist them to the fs as a file. I was hoping to sync workouts at the user's discretion - put the "workouts" file on you Google Drive or whatever and just load it using the app when you use it. It wasn't possible, best I could do was a manual import/export. Worst part was, a few months after I made the app, Chrome dropped a bug on an update that wiped local storage on update, so I lost months of IndexedDB records. I now look at apps like Google Sheets and Google Docs with disdain. Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers). Combine FS access with using WASM as a compile target, suddenly you're writing native cross platform applications in C++, Rust or your language of choice - if WASM ever gets off the drawing board. I feel like the web is an analogy for Fusion, the good part is always a decade away. /rant
- madeofpalk 4y ago
  If we're calling C++/Rust to WASM in the browser "native", then Javascript is native also.
- sgbeal 4y ago
  > Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers). And files which other folks can generate, like marketing malware injected there by out-of-browser applications and/or shady OS vendors (who might pre-populate data for their own sites, as well as business partners' sites (for a fee, of course), under the pretense of "improving user experience"). If browser-accessible storage is accessible to arbitrary out-of-browser applications, arbitrary package updates and installers can _put stuff there_ or overwrite stuff which is already there. We can be certain that such things would rarely, if ever, be to users' benefit.
  - apatheticonion 4y ago

AshleysBrain 4y ago

I agree - the File System Access API with full integration with local files and folders is essential for desktop web apps. Ours[1] supports File System Access for saving and opening projects in Chromium-based browsers, and our stats show a full 65% of users save that way. So it's also what real people actually want to use in browsers. [1] https://www.construct.net https://www.construct.net

tgv 4y ago
I'm basically against the browser getting too much access, so what is missing in Firefox 111 for your use case? Is it just less convenient for end-users?
- AshleysBrain 4y ago
  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.
  - cxr 4y ago
    Browsers have been able to get access to files on disk for longer now than many Web 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 did eventually gain support from all major browsers—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, 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.

illiarian 4y ago

> but the API has to explicitly request for user permissions anyways You mean, just like all other 200 [1] or so APIs that want to request that access? It's a good thing some browser vendors don't look at these APIs in isolation, but look at the whole picture. So they see all the other APIs that also want to spring a pop up requesting access to something, and are concerned about confirmation fatigue. [1] Exaggeration. Or maybe not. These days between all the hardware APIs chrome is pushing, and existing APIs like notifications and locations, and half-consensus APIs like file system access and MIDI there might be more than 200 hundred already.

deleted 4y ago
[deleted]
capableweb 4y ago
Seems there are about 18 APIs that require explicit user permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API https://developer.mozilla.org/en-US/docs/Web/API/Permissions... 7 of those are actually available in Firefox at all.
- illiarian 4y ago
  It's definitely more complex than that because many of those APIs have additional areas that may or may not be covered by permissions. For example, Firefox implemented permissions for enumerating MIDI devices, and Chrome didn't, with predictable results: https://twitter.com/denschub/status/1582730985778556931?s=20 https://twitter.com/denschub/status/1582730985778556931?s=20
AshleysBrain 4y ago
Arguably looking at the whole picture means recognizing that some of these use cases will instead be done by traditional desktop apps that have far more invasive access often without needing to prompt the user for permission at all. In my view web browsers are a more secure and privacy-preserving option than that.
- 4y ago

BlueTemplar 4y ago

If your app is complex enough to need something like this, you probably should make it native anyway (the browser interface is going to get in the way). Don't try to turn the browser into an OS ! (I probably shouldn't give any support to Windows by even mentioning it, but doesn't it have built-in sandboxing and especially permissions too these days ? What else the "run as an admin" command is about ??)

afavour 4y ago
> If your app is complex enough to need something like this, you probably should make it native anyway Are we really still making this argument in an era where Figma and Google Docs exist?
- norman784 4y ago
  Don't they save the files on the cloud? I think this is about having access to local file system.
  - afavour 4y ago
    My point isn’t about local file system access. OP said that if you’re making a complex app it should be native. I was pointing out that millions of people use complex webapps every day, adding file system access is a logical attempt to meet an audience where it is.
    - BlueTemplar 4y ago
      I'm not blaming Mozilla here (at least I don't think I should..? Not sure that the «enabler of bad behaviour» argument can really apply here ??)
  - Steltek 4y ago
    I wish it wasn't a local filesystem. Google Docs was superior (for me) in that my files were available on every device. To achieve that here would require setting up Dropbox or similar and dealing with edge cases. If this API was more sophisticated with conflict resolution, Firefox could sync these files for me (maybe S3 compatible? I dunno) and then every app could have magical Dropbox/GDrive capabilities instead of a boring old tech folder that gets wiped out every so often.

reportgunner 4y ago

> I'd much rather live in a world where I can briefly use a web app to do some task than be forced to install a myriad of native desktop apps that have unsandboxed and unpermissioned access to everything on my system. I just use a vanilla install of chromium for this.

pjmlp 4y ago

Unfortunely it harldy matters anymore if they implement something or not. On all our projects it is already downgraded to "nice to have" status, if it matters at all.

mihaaly 4y ago

I wonder if the argument is here then to make the browsers as secure as a desktop app by giving them all the possibilities of a desktop app? Giving web and desktop apps the same access - temporarily or permanently alike, no difference - to local data and system will make both the same secure. Or the web one being even less secure as that is inherently remote centered while the desktop could be restricted to local. Ultimately nothing is secure with a non-paranoic user nowadays so idealisticly no reason not allowing the same access to a web app. But oh there is! Knowing that one does not need to worry at least about a surely web app digging around in the local system above desktop apps that may or may not send local data somewhere is better. Should mitigate the risks not aggravate! Btw. desktop apps has no unpermissioned access to everything on your system.

kitsunesoba 4y ago

For what it’s worth, mac apps have had disk access permission prompts (along with prompts for several other permissions) for a while now. Its permission system isn’t perfect, but it’s a far cry from unpermissioned access. Windows and Linux do have a way to go in this regard, though. I’ve seen efforts from the Elementary OS team to include some form of permissions in their distro but I’ve not seen it elsewhere in desktop OSes aside from macOS.

vetinari 4y ago
> but I’ve not seen it elsewhere in desktop OSes aside from macOS. Flatpack-ed applications on Linux do have similar sandbox.
- c-hendricks 4y ago
  Windows does as well. But like Flatpak, I think they're handled at install time, not at-access time.

nullfield 4y ago

I don’t like OPFS much more; almost less, in fact. “It is not intended that the contents be easily user-accessible” is different from “it is intended that the contents not be easily user-accessible”, and they sure seem to be trying for the latter when they don’t need to, especially given that we know it’ll be a short matter of time until OPFS is being abused in some way.