I think it's great, but we're still far off from an ideal solution because it's not exactly fine-grained. For example, flatpak portals enable me to grant/block access to my home folder, but don't enable me to allowlist a specific folder in my home. So i'm stuck with the possibility that a vulnerability in the app can take over my entire system (eg. by rewriting ~/.profile), or with my app not accessing my home folder at all.
As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
>As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.
So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up.
Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know.
I forgot what exactly the problem was with Vscode(/ium), but it also has a catch like that. You just gotta know.
Flatpak turns out to be the best compromise between distribution and cross distro compatibility, but there's still some low hanging fruit that could be improved.
It's not true they assume full write access to ~, they just don't propagate they limitation of a constricted choise of paths in their GUIs. Because they isn't a way to do that, GUI toolkits don't really provide a way to clearly communicate you can only save/open in a specific dir.
