The thing is that messaging is the important bit here.

If I have Debian apt archives in my sources.list, I understand the risks, just like a pure Windows user does: other than bugs, you might be affected if someone hacks Debian/Microsoft and that's it (or, of course, someone internal to them decides to do it).

Flatpaks/snaps are designed to be built by less-trusted parties and promise things they know they can't deliver on. Now I am suddenly asked to trust these external developers that they will be as adamant with security fixes, be non-malicious, etc. And flatpak/snap are trying to convince me how that's a non-issue "because sandboxing".

Sure, we here understand the underlying technologies so we can make our own educated guesses, but majority of the people who this is aimed at don't.

Since you also mentioned "add a new repo", there are some repos you can trust even if they are not the official ones. PPAs on Launchpad build from source packages, so you can always get the source first ("apt-get source package" after adding the repo). If someone is just bundling binaries and the build is a no-op, you can drop the repo right away. Sure, it requires some effort and you won't be checking every repo, but for sufficiently popular repos, somebody would be doing that.

It'd be ideal if apr grew support for limiting packages that can come out of a repo, so you'd have to whitelist when something new pops up ("hey, this repo has now introduced libc version X, and your libc is coming from repo main: do you want to allow upgrades from non-main repo to libc? [only once] [yes] [no]").

I decided to look at the messaging - the websites of both Flatpak[0] and Snap[1] make no claims about security, or about being "designed to be built by less-trusted parties".

Both of them focus more heavily on the convenience of distribution than any user-facing benefits such as sandboxing.

If you're referring to the GNOME Software "Sandboxed" badge, it still indicates that there are some universal properties of the sandbox. (For example, flatpak apps live in their own PID namespace and cannot see what other processes are running on your system.) Also, there is a permissions badge on the right that does indicate the level of access you'd be granting to the app. (Full $HOME access is indicated with High, and a click on the badge tells you exactly what it needs.) There could be some work needed to do around guarding `.bashrc` and similar, though.

In addition, Flatpaks and Snaps are both served as repos - a `.flatpakref` for instance is just a reference to a repo. Using a `.flatpakref` to install software is like adding a repo to your sources.list, but in ways more secure:

1) Flatpak doesn't have the concept of install scripts (and doesn't have a way to install a setuid binary), so just installing an app won't cause a security hole. On the other hand, a `.deb`/`.rpm` can run arbitrary code as root in the install scripts.

2) Packages on Flatpak are scoped to the repo you installed them from - for example, if you request `org.gnome.Calculator` from flathub, another repo can't serve version 10000 of the same app and have users install it. If the same app is available on multiple repos, flatpak will prompt you and ask what version to install.

example output for `flatpak install org.gnome.Calculator`:

Remotes found with refs similar to ‘org.gnome.Calculator’:

   1) ‘fedora’ (system)
   2) ‘flathub’ (system)

[0]: https://flatpak.org [1]: https://snapcraft.io

"Convenience of distribution" is, by nature, targeted at application distributors which are not the end-users I (or the OP) claimed to be affected by the messaging.

So yes, I think the messaging in GNOME Software should be improved (hard for me to check on Ubuntu because it does not come with Flatpak support on by default).

Note that ".bashrc and similar" is a huge amount of files (just off the top of my head, .profile, .zshrc, .cshrc, .Xsession, .xinitrc, .ssh/config [for eg. ProxyCommand]... you get the gist).

So the tradeoff is "weak sandboxing, or up-to-date security patches".

TBH I don't know which I prefer. But I suspect the lack of security patches will continue to get worse and worse as time goes on.

The sandboxing is not always weak. On most apps its almost fully locked down and has access to only your downloads folder. Its only things like vscode which need everything.

You can also manually set permissions using flatseal to lock it down as much as you want.

Putting a blue shield on "sandboxed" when allowing (write!) access to my home directory falls on the extreme side of "weak" to me.

Sure, they are capable of locking it down better. But they haven't in 2+ years. It shows where their priorities are.

Flatseal I'll have to look into though, thanks! A user-controllable method is always a plus, and I do love sandboxes. Most apps need very little access, and locking them down prevents a LOT of kinds of misbehavior, intentional or accidental.

Access to a shared downloads folder doesn't sound “fully locked down” to me. I can imagine situation where I wouldn’t want one app to see what is downloaded by other apps.

Would be better if each process had its own downloads folder (it’s own file system namespace even).

Thats why I said "Almost fully locked down"

Each flatpak app does have its own namespace and dir it can save whatever it wants to. Some packages like the MS teams one have been given access to downloads only so you can share files with people. You can turn off this access if you want.

Flatpak also has a thing called portals which let the program request a privileged filepicker so the user can select any file and the filepicker grants access to it for the program. The problem is not all apps are set up to work properly with this right now.

Flathub actually does review submissions reasonably well. You have to give a justification for each permission you request and why it couldn't be done in any other way.