> Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model.
The problem with Android's "fine-grained run-time permission model" is that most users learn very quickly that if they don't grant Android apps all the permissions that they ask for, they won't have the app's full functionality. I have played this game many times with Android apps, where I only grant them the permissions that I think are strictly necessary. However, after I start using the app, I constantly discover that I keep needing to grant them more and more permissions. In the end, it becomes such a hassle to keep being asked for permissions, that I almost always end up giving every app all the permissions that it asks for.
It is far better for most users to have their apps preconfigured to only grant the permissions that they need by distros and companies who care about protecting users and keeping their data private. As a user, I don't want to have to scrutinize every app that I install and check whether the business model of the app creator is based on surveillance capitalism or malware. Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me. Yes, I know that Firefox is paid to set Google as the default search engine and Canonical tried a few schemes in the past like its Amazon Shopping Lens in 2012-16, but those are anomalies in the Linux world, whereas they are the norm in the Android world.
> Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all.
Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla, and I know that the F-Droid community did a good job of reviewing the code that I submitted to them. I have a personal beef with how Daniel Micay treats other FOSS projects, but GrapheneOS does a good job of protecting its users. However, I know from personal experience that I always end up installing apps based on surveillance capitalism on my AOSP phones, because I always end up needing some Android app. In 27 years of using Linux, I haven't installed any malware or spyware that I know of (beyond Firefox's Google search), and that is the common experience of most Linux users. (See below for further argument.)
> This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc).
If you are arguing that mobile Linux needs to improve its userspace security model, then I agree. I'm not saying that Flatpak is perfect. My argument is that it is much easier to improve mobile Linux's security model than to fork AOSP or even just replace the user anti-features in each new release of AOSP.
> The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
True, there have been instances, such as OpenSSH's CVE-2026-35414, where they didn't catch the problem for 15 years, and you mentioned the xz backdoor, where someone (probably the Israeli government) was deliberately introducing security holes. In general, the Linux distros have been lulled into a sense of complacency since they haven't had major security issues like Windows and Android have had in the past. I think the real issue is the fact that the major Linux companies (IBM/Red Hat, SUSE, Canonical and Google) are mainly focused on servers, where userspace security isn't an important factor. If your argument is that mobile Linux won't be able to implement a better userspace security model without the help of the big Linux companies, then you may have a point. However, the example of Qubes demonstrates that it isn't impossible for a single distro to implement major changes.
The problem with Android's "fine-grained run-time permission model" is that most users learn very quickly that if they don't grant Android apps all the permissions that they ask for, they won't have the app's full functionality. I have played this game many times with Android apps, where I only grant them the permissions that I think are strictly necessary. However, after I start using the app, I constantly discover that I keep needing to grant them more and more permissions. In the end, it becomes such a hassle to keep being asked for permissions, that I almost always end up giving every app all the permissions that it asks for.
It is far better for most users to have their apps preconfigured to only grant the permissions that they need by distros and companies who care about protecting users and keeping their data private. As a user, I don't want to have to scrutinize every app that I install and check whether the business model of the app creator is based on surveillance capitalism or malware. Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me. Yes, I know that Firefox is paid to set Google as the default search engine and Canonical tried a few schemes in the past like its Amazon Shopping Lens in 2012-16, but those are anomalies in the Linux world, whereas they are the norm in the Android world.
> Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all.
Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla, and I know that the F-Droid community did a good job of reviewing the code that I submitted to them. I have a personal beef with how Daniel Micay treats other FOSS projects, but GrapheneOS does a good job of protecting its users. However, I know from personal experience that I always end up installing apps based on surveillance capitalism on my AOSP phones, because I always end up needing some Android app. In 27 years of using Linux, I haven't installed any malware or spyware that I know of (beyond Firefox's Google search), and that is the common experience of most Linux users. (See below for further argument.)
> This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc).
If you are arguing that mobile Linux needs to improve its userspace security model, then I agree. I'm not saying that Flatpak is perfect. My argument is that it is much easier to improve mobile Linux's security model than to fork AOSP or even just replace the user anti-features in each new release of AOSP.
> The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
True, there have been instances, such as OpenSSH's CVE-2026-35414, where they didn't catch the problem for 15 years, and you mentioned the xz backdoor, where someone (probably the Israeli government) was deliberately introducing security holes. In general, the Linux distros have been lulled into a sense of complacency since they haven't had major security issues like Windows and Android have had in the past. I think the real issue is the fact that the major Linux companies (IBM/Red Hat, SUSE, Canonical and Google) are mainly focused on servers, where userspace security isn't an important factor. If your argument is that mobile Linux won't be able to implement a better userspace security model without the help of the big Linux companies, then you may have a point. However, the example of Qubes demonstrates that it isn't impossible for a single distro to implement major changes.