No, you are confusing flatpak with sandboxing. Sandboxing is a good thing. You don’t need flatpak to implement sandboxing. Additionally, good sandboxing has to be configured by trusted 3rd parties, like package maintainers, not by upstream developers, because the latter creates a conflict of interest.
All in all, most problems with Flatpak are problems, that can be solved
No, flatpak and similar things are designed to bypass the relation of trust between end users and Linux distributions. Users are required to either blindly rely the upstream authors with the sandboxing, privacy, legal compliance and general quality or do extensive vetting and configuration by themselves.
Additionally the approach of throwing every dependency in one big blob removes the ability to receive fast, targeted security updates for critical libraries (e.g. OpenSSL). And there is no practical way to receive notifications for vulnerabilities and to act on them for the average user.
Traditional Linux distributions carefully backport security fixes to previous releases, allowing users to fix vulnerabilities without being force to upgrade their software to newer releases. New releases might contain unwanted features or be too heavy for older hardware, or break backward compatibility.
With Flatpak, even if the upstream developer forever releases new packages every time a vulnerability is found in the entire blob, end users are forced to choose between keeping the vulnerable version or update it. Plus, the authors might simply abandon the project.
Furthermore, Flatpak, Snap etc and similarly Docker do not require 3rd party / peer review of the software. Given the size of the blobs it would very impractical to review their contents even if it was required.
This is a Flatpak problem. Its design requires the user to either trust the upstream developers to set the sandboxing properly or learn how to do it and spend time configuring each and every application as needed. This is not practical.
In traditional Linux distributions there is a trusted package mantainer that reviews software and configurations with the user’s needs in mind.
Interesting! Projects like https://sensor.community/ might be willing to collect such data.
Alternatively you can buy a Lichee RV. They seem to be still cheaper. https://www.aliexpress.com/item/1005003741287162.html
Can you please share details about this one?
Edit: if you are referring the following… it’s not RISC-V: https://hackaday.com/2022/04/01/mangopi-to-bring-a-sd-card-sized-linux-module/
You can also buy the Lichee RV and its dock, but it increased in price recently: https://www.aliexpress.com/item/1005003741287162.html
Details and installation instructions on https://wiki.debian.org/InstallingDebianOn/Sipeed/LicheeRV
Sealed sender does nothing against timing correlation. It’s really trivial correlate traffic over TCP connections and find out which pairs of IP addresses are communicating with each other.
Unsurprisingly, it’s ineffective against users that exchange messages very rarely and effective with users texting every day.
Signal does nothing to mitigate this problem.
You are confusing package maintainers with upstream developers. They are not the same people, and this is by design in most distros, so that maintainers provide a second pairs of eyes, provide security fixes and sometimes remove trackers and similar “features”.