Also, there is a risk of a site writing malware executable, and Linux currently has no sandboxing for such executables so the system would be completely owned once the user runs the program. So the directory should not allow storing executables.
Also, there is a risk of a site writing malware executable, and Linux currently has no sandboxing for such executables so the system would be completely owned once the user runs the program. So the directory should not allow storing executables.
I think the WebKit take on this is good and a better fit for most apps. They instead implemented Origin Private File System. Which is based on the same API bits but the folder is only accessible by the website. The downside is the user loses some control over the files:
- can’t see what’s being stored
- can’t easily backup those files
- has to use that web app to access the files
- usual nonsense about important files being classed as “cookies” or some nonsense by cache cleaning tools, leading to users deleting their data without realising it
Why not use some human-readable path like ~/Internet/example.com/ ? In this case the user could see the files.
Firstly if an app does want a space that’s filesystem shape but does not want users/apps to have access for security or consistency reasons ( think Spotify offline storage of songs ).
Secondly if the user has access they can do the “easy” thing and just throw lots of files in, including things which are sensitive anyway.
It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.
Then they should not store anything on user's device.
> Secondly if the user has access they can do the “easy” thing and just throw lots of files in, including things which are sensitive anyway.
OS could add a warning when copying the files into the folder.
> It’s interesting to look at how Android and iOS have handled filesystem sandboxing in relation to this.
Many apps on Android request "media access" which allows accessing all user files.
Origin Private File System is for files that the app manages internally and that normally, the user should never touch - like stuff in /var or AppData for native applications. Hence why browsers make no guarantees where on disk they will store those files or even if they'll store them as files at all.
But I think that's not really very interesting, because it's not offering anything new you couldn't already do with localStorage or indexedDB, just with a file-like API. Hence why browsers also put it in the same "ephemeral local data" bucket as those APIs.
The directory picker API would offer a new ability, namely to "open a directory" in user-managed space and work with it like an IDE would. But I can see why the security risks are too large for that.