What's the point though? Either the software is evil/has a bug that lets it steal all your data, or it doesn't.
Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files?
If the app is a web browser then fair enough, but what other apps would that be useful for?
I was trying to address multiple points that sometimes are made here and else where regarding stricter access patterns. This would probably involve a more complex (as in with more options) permission system, or perhaps can be achieved under linux with groups.
> What's the point though? Either the software is evil/has a bug that lets it steal all your data, or it doesn't.
The program itself might be updated to a compromised version, where the gatekeepers are compliant or by a change that passes review, or you might want to test a program and not have to worry about running a vm or a docker container. For package managed programs this is not so much an issue with linux where you usually will update it yourself, but anything using auto-updates can fall prey to it. The same with npm et al.
> Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files?
The app wouldn't have any specific filesystem, it would be given a role/group/wtv that could be used to assert permission when accessing files or system apis. Say I download chrome, chrome creates a folder named "chrome", it can only, by default, write to that folder and read from that folder.
For anything else it needs to ask the OS for permission and I can grant it, for a single usage (the file as is in that point in time is read and passed to the app), for a single session (until the app is exited it can re-access that specific file without prompting) or until I revoke it (it can access that file without prompting until I revoke the access). When it needs to access a file or api, outside of those currently allowed it needs to ask again.
The folder was in terms of one of the complains of permissions making the UX worse when you need to give permissions to the app. So in this case, chrome could store its downloads inside that folder, the save Page as, download image as, etc.
Ideally it would have enough granularity to distinguish between modes of access, so I could give it permission to save on my "docs", but it wouldn't have permission to read other files in the folder that weren't granted permission - it would be able to read though the files it saved by default, because those would default to be readable as well (since the program was the one writing them there's no point in changing that).
The permission could be changed as well and changing the file from one "folder" to another could/would automatically reset the permissions (perhaps the permission would be an hash of the current directory + an app key). When upgrading versions the OS would have an easy way to migrate current permissions, generating a new copy of the current permissions from app key to a new set assigned to the new app key (the app key could be an hash of the current program folder as when installed). This would be something like a panel where you could see all app icons/or in text mode their names, and click one, and say, import to X, or do copy-permissions chromev12-xssdcfdsf to chromev13-shfghhjh. Or right-click the icon for the app and have one of the options be "import permissions from", etc.
If a program doesn't need to do any of these then it wouldn't need to have a folder but most programs will have some sort of necessary file storage, be it config, etc.
This same permission model would then work for OS api/hardware/wtv access. Open zoom and it needs mic and cam, you can give it permission just until you quit it.
This is also true when it comes to programs that have sudo requirements to be run. I'm not saying that you can't take precautions to mitigate any of this if you're paranoid, I just think it should be the baseline. There shouldn't (ideally) be any need for me to run jails, VMs or anything to try a program or installed libraries to be used.
If I on a phone use an app that can send, for instance images or any other files, but also store them, I should only need to give it write access to a folder but not read. Because unless it's going to do reading by itself without me instantiating the action, whenever I want to send a file, the OS can prompt me and I will pick the file, and this wouldn't even need to change the access level to that file, the os could just provide the file for that single interaction.
Right, fix the permission system, every app has its own scratch space, but needs to talk to the os file protection layer to load/save, if you double click a file, it has permission to read it, if you save a file it has permission to write and read it.
Very few desktop apps need permission to read/write files you didn't select manually anyway.
Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files?
If the app is a web browser then fair enough, but what other apps would that be useful for?