They also rely on the deprecated SUID-root binary FUSE2.

There is no such thing as a suid fuse2, you are talking about suid fusermount, and libfuse2 which hasn't been true for 3 years the runtime is now static and doesn't depend on any libfuse (or any library) to work.

And even back then it wasn't a hard dependency either, you could still run appimages by setting APPIMAGE_EXTRACT_AND_RUN=1 which makes them run without FUSE.

The runtime still depends on a suid fusermount in PATH (it checks all the way to fusermount99 lol), however there is a much better runtime that does not FUSE to work at all since it can use mount namespaces instead.

Meanwhile flatpak has a hard dependency on fusermount, it actually broke recently on ubuntu because they wanted to restrict access to fusermount.

but if given access to the “home” permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission.

web browsers (and electron apps) already have their own internal sandbox, which actually gets weakened by flatpak so it is actually not a good idea to be running those things with flatpak 1 2 3

firefox recently finally got a fork server in linux, which means it is possible to at least get the zypack hack working with it, no idea if it has been implemented yet though.

You also can sandbox appimages with bubblewrap, which is the very same sandbox flatpak uses, I wrote this tool used by AM for that.

Apps will also have access to the portals, although I don't like this and looks like there is no easy way to disable access to portals other than disable all access to dbus which is bad.

We already had an incident where someone thought there was a sandbox escape when it was just the app opening the portal xd