Now, it's certainly debatable if flatpak could or should push more in that direction, like apple did when they introduced the sandbox for app store applications, but flatpak certainly does not have leverage to the same extend as apple has. So it's up to the app to opt in to a suitable sandbox set. It's a sad state of affairs, but I don't see a viable path for the flatpak folks to change that.
Whether flatpaks is better or worse than packages depends on many other factors. Flatpaks allow software providers to package for multiple operating systems in one package, for example. This makes software available that otherwise wouldn’t be. Whether that’s worth it or not is debatable, but raising clearly invalid points to attack flatpaks is disingenuous.
And it is easy to fix - publish capabilities in the gallery. Apple iOS "request location" shows that people care if they know. Sandbox certainly is a good thing. Without it Flatpak is just another package manager.
> It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system.
https://en.wikipedia.org/wiki/Flatpak
> flatpak(1):
> ... isolated from the host system ('sandboxed') to some degree, at runtime.
> One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment.
https://docs.flatpak.org/en/latest/sandbox-permissions.html
And a lot more
Maybe we can trust big names, just like on Android — Google, Amazon. We may think that it is safer with paid software — they have something to loose. But free - I'd bet on maintainers.
The old thinking was that software was a user agent, serving the user's needs and interests. Some OSes (Debian comes to mind) explicitly acknowledge this.
Increasingly it's simply a naive and unjustified belief. Applications must be considered as untrusted necessary evils. Allocating them a minimum level of access is prudent.
Flatpak promises this, but fails to deliver.
Package managers offer this by convention, but rely on users (and security researchers) discovering and reporting malicious behaviour. Mitigation is retroactive: fixed behaviours or packages removed from the distro's repository, but the damage is done and existing deployments remain.
The underlying issue is one of packaging, updating, and distributing sandboxed apps.
And in recognising that packaging systems serve users, not developers.
Snap/Flatpak were meant to solve that issue.
Edit: There's also the fact that practically most packages on Ubuntu or Debian, for example, are outdated.
This "issue" was already solved by static executables. Snap and flatpack are the work of computer illiterates.
What I value most is having every software or library available through some form of package manager. Downloading static binaries off the internet without auto-update just doesn't make it which is why I like having Flatpak as a fallback.
It also makes it easier for the common user to have every piece of software available through one store. They don't need to know whether it's a .deb or a Flatpak underneath, it just needs to be there and work reasonably well.
There's really no other option: either distro maintainers include every single piece of software in the repositories (unlikely), or we need a common format that works on all distros (already the case with Flatpak).
On the maintainer/author side, yes, I think static binaries largely perform the same.
And they do? Just because they have some flaws doesn't mean that they're completely unusable. If you need an app that isn't on your distro but is on Flatpak, by all means use it.
Some reasonable level of quality control does take time. There are distros that are much more up to date with upstream versions (Arch Linux, Gentoo, etc), but by living on the bleeding edge, you will eventually get cut.
BTW, I used to think that we can just provide a prebuilt binary to let user download from a website, but finding that isn't easy to achieve unless you use a language like Go, Rust... because I found that many C program are hard to compile with full static linking.