I am excited about flatpak for multiple reasons, which boils down to sandboxing:
1. Proprietary software: most proprietary software authors do not play well with packagers. Moreover, I want any proprietary software properly sandboxed
2. Software that you need sandboxed for various reasons: I've been running flatpak nightlies of stuff I otherwise have installed on my system
3. Installing a program without installing a whole bunch of dependencies, hard to clean up after
4. Cleaning up my home directory
Sandboxing (I know most flathub packages have leaky sandboxes, but that's a start) limits the effect of compromising one flatpak. To be clear: I treat any piece of proprietary software as a possible RCE by the author.
User themes issues are probably fixable.
Slower startup as well, to an extent.
Unfortunately, developers are pretty bad at packaging generally, and don't have distro maintainers watching over their CVEs and upgrading dependencies with the flatpak model... Although users could still dig in and fix these by themselves, and sandboxing still gives a few protections.
You will have to elaborate instead of throwing easy accusations like these. Linux namespaces are pretty tight, and I make sure that flatpaks that need sandboxing have the right sandboxing mechanisms in place.
In order:
1. Filesystem access is one of the most critical pieces (to me). Flatpaks on flathub often restricts this by default, except for a few packages. Portal mechanisms offer on-demand access to external files and folders.
2. X11 access: I use wayland, and make sure the program I'm launching does too. There is a X11-fallback scheme that blocks access to X11 if wayland is being used.
3. Network access: I usually leave it enabled when needed, there is not much to exfiltrate if filesystem isn't accessible, and that's the main threat I'm concerned about.
I am not very concerned with Pulseaudio, pipewire socket or access to select D-Bus paths.
Sure, it is not an air-gapped computer, nor a virtual machine. The attack surface is bigger, but not that much.
I'm going to go ahead and presume that anyone intending to release a malicious app or compromised update to a non-malicious application has access to a similarly configured system.
They are thereby incentivized to attack via a method that is successful on their test systems. In particular applications set their own initial permissions (can they also update themselves and acquire greater permissions without user input?) and often contain old outdated and potentially insecure known insecure versions of software already patched or updated in distro repos.
If you put up $1000 and offered to install any malicious app on a current fedora gnome default install VM and see if someone could pwn it your money would be gone in a few hours. You could do this once a month between now and 2025 and I would be surprised if you were ever able to retain your money.
1. Proprietary software: most proprietary software authors do not play well with packagers. Moreover, I want any proprietary software properly sandboxed
2. Software that you need sandboxed for various reasons: I've been running flatpak nightlies of stuff I otherwise have installed on my system
3. Installing a program without installing a whole bunch of dependencies, hard to clean up after
4. Cleaning up my home directory
Sandboxing (I know most flathub packages have leaky sandboxes, but that's a start) limits the effect of compromising one flatpak. To be clear: I treat any piece of proprietary software as a possible RCE by the author.
User themes issues are probably fixable.
Slower startup as well, to an extent.
Unfortunately, developers are pretty bad at packaging generally, and don't have distro maintainers watching over their CVEs and upgrading dependencies with the flatpak model... Although users could still dig in and fix these by themselves, and sandboxing still gives a few protections.