And your chance to share this complete control with every installed app. Phones should be like desktop computers. You install an app, you give it access to everything your account can touch on the computer.
So many iPhone users knowingly refuse to upgrade to newer versions of the operating system just so they can keep their jailbreak.
People do that all the time with desktop computers.
Maybe. I'd argue "extremely".
It does suck, for instance, that Discord as a Flatpak can only access a fixed subset of $HOME directories. But it can't scan your machine's processes like ordinary Discord can (to report the game you're playing), which is a privacy gain. The security (and portability) advantages of sandboxing/containerizing apps may outweigh the hassle of the workarounds/memory inefficiency.
Meanwhile, with unfettered access, you have things like: https://www.thegamer.com/civilization-6-steam-eula-change-sp...
>"We may combine the information with your personal information and across other computers or devices that you may use"
They also mentioned "photo", which there's no obvious way to collect. I remember someone joking, "What, do they go through your directories, looking for a picture of you?!"
So maybe, instead of trying to somehow make it safe to run untrusted software on our machines, we should focus on making sure all the code that runs on our machines is trusted - not in the sense of "proved correct", but in the sense of "written without malicious intent". If you regard Discord scanning your processes as an unacceptable invasion of privacy, and it bothers you that there's no way to turn that off, perhaps avoiding Discord is a better solution than trying to sandbox it.
Using a separate computer for each counterparty would be more secure, but again not very convenient.
For programmers and experts no.
But if it was toggle-able, I would toggle "sandbox everything, don't let anything not secure run, only allow trusted apps" in a heartbeat for work machines, my parents, and so on...
You mean a security model that misses the fact that the kernel cannot be updated and relies on a "sanboxing" solution that doesn't bother limiting kernel attack surface. No, I don't think they even had a security model in mind, a threat model or anything beyond random ad hoc ideas. And if they did some thinking, they would not have chosen SELinux either, as it's not a decent solution to anything, it's more like a solution to "we must to do something, this is something, we must do this".
Managed languages userspace, drivers implemented in Java or C++ in their own process with IPC to the kernel (since project Treble), whitelist of allowed native calls beyond the rather thin set of native libraries, to touch IO beyond own APK install dir or TCP/IP, native code needs to go through managed layer, several security critical processes are deployed in production with FORTIFY and sanitizers turned on.
ChromeOS turns the notch even higher by running Crostini on its own Rust implemented hypervisor and Go written userspace syscalls wrapper (gVisor).