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’:
"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).
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]").