>The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.
The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc.
It's really hard to conceive of how these programs would work without some of the requested permissions. I remember the hazards of trying to get a proper IDE on ChromeOS some years back because of Google's own sandbox restrictions on allowing extensions to access the chromebook's filesystem. IIRC there was a company that even created "cloud-IDE" environments to get around this limitation.
Couldn't it be possible to ask the user to allow certain directories or files? It might be kind of annoying but it would be safer.
Also, it could integrate with the open file dialog and only allow the application to access files selected by the user, and nothing else. That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care. But that would be ideal since it's safe but also not annoying.
> That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care.
For GTK apps, they don’t need to do anything different, as GtkFileChooserNative[1] is recommended for non-sandboxed apps as well. GtkFileChooserNative has glib call the D-Bus API (which is proxied inside the sandbox) for the FileChooser portal[2]. The backend running outside the sandbox (xdg-desktop-portal-gtk for GNOME/GTK; there are also backends maintained by KDE and wlroots developers) shows a file chooser and makes any file (since March 2020, there is also support for folders) selected by the user available inside the sandbox using the Documents portal.
Also the portal APIs are not specific to Flatpak. They can be used by any sandboxing framework that wants to benefit from the work already done to integrate them.
Some apps don’t use GTK or Qt, some apps (like GIMP) still use GTK 2, which doesn’t have GtkFileChooserNative, and some apps haven’t been ported from GtkFileChooserDialog to GtkFileChooserNative (or can’t be ported yet because of missing features in the latter). And the Documents portal doesn’t work perfectly for all use cases: There are issues with getting notified when a file is modified externally and with getting the path of the file outside the sandbox (to display it to the user, if that’s desired).
The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc.
It's really hard to conceive of how these programs would work without some of the requested permissions. I remember the hazards of trying to get a proper IDE on ChromeOS some years back because of Google's own sandbox restrictions on allowing extensions to access the chromebook's filesystem. IIRC there was a company that even created "cloud-IDE" environments to get around this limitation.