> People often argue that using AOSP will provide access to more software, but that is not necessarily true if the goal is to only use free/open source software (FOSS). Google deliberately obscures the licensing of an app’s code from users by labeling both freeware and FOSS as “free” in its Play Store. There may be more total FOSS among those two million apps in the Play Store than in the Linux repositories, but selecting out the FOSS apps, vetting their code and organizing those apps into a separate repository will not be an easy task.

Vetting apps is an ongoing and imperfect task on desktop Linux as well. The Accrescent app store which is currently in development for Android will in the future offer a filter option to filter actual FOSS apps from proprietary apps. Labelling apps properly really isn't impossible.

> In contrast, Google is constantly changing the standards for its apps and forcing app creators to constantly update their code to keep their apps in the Play Store.

This is also due to the introduction of new privacy and security features that are part of newer SDK levels. That's part of the user empowerment you wanted to see. If Linux would add user-friendly security and privacy features that are mandatory, a lot of apps would also need updating.

> None of this is to suggest that AOSP is necessarily bad or that people currently using AOSP phones should abandon them. AOSP derivatives like LineageOS, crDroid, Evolution X, /e/OS and GrapheneOS provide an invaluable service to people seeking privacy and greater software freedom, plus the ability to extend the lifespan of their phones.

I don't know anything about crDroid and Evolution X, but LineageOS and /e/OS in particular really don't offer people privacy. See the great blog posts from Mike Kuketz which you can translate to your own language about custom OSes and their privacy and security: https://www.kuketz-blog.de/android-grapheneos-calyxos-und-co... . Also, see the comparison of Android OSes by Eylenberg for notable security and privacy differences: https://eylenburg.github.io/android_comparison.htm .

The claim that custom OSes expand the lifespan of phones is often misleading. They need manufacturer support to ship driver and firmware updates and those are necessary to have a properly secured phone. You can't un-EOL a phone by putting a custom OS on it.

> If our goal is the empowerment and greater freedom of people, mobile Linux appears to be a more feasible route to achieve those goals in the long term than AOSP.

There is little empowerment if you can't really decide what you give apps access to.

> Even when those Android apps are run inside an LXC container, mobile Linux still needs to be prepared for all the malware and spyware that comes with running Android apps.

Doesn't make sense to want to use a more secure and private OS as a guest on a less private and secure host. It should be the reverse. LXC containers also aren't proper isolation like a VM.

You can perfectly run malware and spyware on desktop Linux, nothing is preventing you technically from doing so. On Android, contrary to desktop Linux, the system will prevent those apps from having invasive access to your system and user data, because of the permission model. On Linux, malicious software has more invasive access and can more easily escalate to even higher levels of access.

> However, adding good userspace security to mobile Linux won’t be nearly as much work as adding user empowerment features to AOSP. It will be difficult to convince long-time Linux users to accept application sandboxing with separate users and separate file encryption for each app, and it will probably require some experimentation to get the right balance between security and freedom. Nonetheless, it is wrongheaded to treat the dev work for better security in mobile Linux as an insurmountable task.

It's not wrongheaded. It will break a lot of software. It will ask a lot of time. Time which is reinventing the wheel because Android exists. And it will get a lot of counter from a desktop Linux culture which seems to care little about security and mostly cares about being able to modify as much things as possible to the extent of even being able to break stuff, because 'freedom'.

> It is important to recognize, however, that many Linux phones either come with AOSP preinstalled or have it installed by their users in order to run Android apps. Almost every mobile Linux distro provides instructions and packages to install Waydroid and microG. Jolla’s license for Sailfish OS includes its proprietary AppSupport. FuriLabs’ FLX1/s/s+ includes Andromeda, which is its fork of Waydroid. All of these solutions run AOSP inside an LXC container. In addition, Valve just open sourced Lepton, which runs Android games as a non-root user in an AOSP container, but it doesn’t include Google Play Services or microG.

Those Android subsystems are almost always heavily outdated and have their security degraded. To give two examples: Waydroid doesn't use SELinux so doesn't have proper application sandboxing anymore and Sailfish OS is at Android 13, while we are currently on Android 17.

> Many of Google’s proprietary Play Services have been replicated by the free/open source microG, which uses signature spoofing to make Android apps believe that Google Play Services are installed. Nonetheless, microG doesn’t always work correctly in some situations, such as Google Maps’ geofencing, in-app billing, AR, SafetyNet/Play Integrity attestation, reCAPTCHA, PackageInfo.signingInfo, etc. Some apps fail security checks in Waydroid, because it appears to be a rooted Android device.

A solution like sandboxed Google Play used by GrapheneOS doesn't have most of the issues MicroG has. It's unaltered Google Play forced into the regular app sandbox. The only thing that really doesn't work with it are apps enforcing strong Play Integrity, which is an anti-trust issue that hopefully will be resolved in the future by regulators.

> Presumably Jolla’s AppSupport has been receiving AOSP upgrades, but Waydroid needs to be better supported in the future if Linux phones are going to rely on it to run Android apps.

Their official site says they reached Android 13, we are currently on Android 17.

> Instead of wasting resources on trying to fork AOSP, we should instead be focusing on how to better support Waydroid and microG for people who need to run Android apps.

Makes little sense to focus resources on the options to run Android apps insecurely. Better would be to donate resources or contributions to GrapheneOS and the GMSCompat project of GrapheneOS which enables running Google Play into the regular app sandbox.

> It won’t be an easy task, because each time Google releases a new version of AOSP, these volunteers will have to rip out the anti-user features in the latest version and replace that code with user-empowerment features. Because Google makes substantial changes to Android every year, the user-empowerment code will likely need to be refactored every year to work in each new AOSP release.

Would be nice if you would be able to give examples of those anti-user features and examples of desired user-empowerment features. New Android versions and SDK levels often bring security and privacy improvements. The permission model has evolved a lot over time and has only evolved to give the user more control over their applications.

> Google is actively rewriting its Android code in Rust to eliminate memory safety vulnerabilities and speed up its software development.

Sounds amazing. What is the issue with this? Do they need to go slow on making the system more secure in order to make it easier for external contributors? Do you think that it would be a net-positive to deliberately slow down taking up Rust?

> The important point is that Phosh is already a very solid interface and the tweaks that it needs are minor compared to the significant dev work that AOSP will require to make it an operating system that respects and empowers users. Even in the case of Plasma Mobile, the dev work that it requires is far less than AOSP would require. The work to improve the Phosh and Plasma Mobile interfaces is a one-time cost, whereas the code churn in AOSP will make it a constant struggle to keep reapplying changes with each new version that gets released by Google.

AOSP respects and empowers users much more than traditional Linux due to the proper security and privacy model, as I mentioned before. Trying to add something similar to Linux would be a very resource-heavy task and will break compatibility with a lot of apps because those are written with the expectation of having wide access to your system. So, you would also have to rewrite those apps, which would make it even more resource-heavy.

> As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.

If this hypothetical scenario that you've been painting in your blog post would happen then it's likely that the large FOSS ecosystem of Android apps will target the community AOSP fork instead of the hypothetical closed source Google Android. There are lot of FOSS Android apps, which can compete with the traditional Linux app ecosystem and even outcompete it for various app categories.

> Linux users are less likely to install rogue apps, because they can’t just find any random Linux software package on the internet and install it, like they can with random APK files found on the internet.

Many people use the AUR. An app being available in a package manager or on FlatHub doesn't mean it's well written or well maintained. And, nobody forces you to grab APKs from random sources, you can stick to reputable app stores or to the official websites and repositories of developers you decide to trust.

> However, Linux phones will need to be able to install Android apps if they are going to appeal to the mass market.

This seems to undermine most of the point you are trying to make.

> Amount of malware and Potentially Unwanted Applications (PUAs) on different operating systems [TABLE]

Kind of irrelevant to look at absolute numbers. Malware and PUAs are hard to define as concepts and it's also difficult to measure or determine whether something falls under that definition. And counting them is also a form of non-exhaustive enumeration.

> Because most applications in Linux are installed from free/open source repositories, there are fewer opportunities to distribute applications that do things that users don’t want such as collecting and monetizing their personal data.

Software installed via traditional Linux package managers is unsandboxed, so it's a beautiful opportunity to collect personal data. Software distributed via Flatpak often requests a bunch of Flatpak permissions and as I said above Flatpak isn't a proper sandbox due to it not being fine-grained, not being properly run-time based and having numerous sandbox escape possibilities. So, also a good opportunity to take personal data. On Android, regardless of distribution means, apps are forced into the app sandbox and subject to a proper fine-grained run-time permission model.

> AOSP is not just designed to protect against malware, which abounds in the Android ecosystem; it is also designed to protect the system against the users themselves. AOSP makes users jump through all sorts of hoops in order to modify the system, because Google and the phone makers don’t want ordinary users modifying the system and customizing the environment to fit their needs. AOSP was purposely designed to restrict the freedom of ordinary users, so they won’t change what Google and the phone makers have preinstalled on their phones.

Exposing this to the user is also adding it as attack surface that an exploit can use to escalate and wreak havoc. Making the system hard to modify is a good way to ensure the integrity of the operating system and apply security features like Verified Boot.

> Then the display name has to be edited in the app’s AndroidManifest.xml file (or its linked string resources). The files have to be recompiled into a new APK package, and then the new APK file has to be signed with the user’s cryptography key. Then, the existing app has to be uninstalled, which means that the user will lose any data stored in the app’s files. Then, the new app can be installed in its place with the new name.

The existing app wouldn't have to be uninstalled if you also changed the app ID, as you are supposed to do. You shouldn't use an app ID used by another developer.

> In contrast, changing the name of an app in Linux usually just involves editing the app’s launcher or creating a link to the launcher with a different file name.

As you admit yourself this is more of a 'launcher' / DE thing than an app thing. So, third-party launchers or launchers of custom AOSP-based OSes could offer custom display names as a feature, just like some offer custom icons. Nothing inherent to AOSP prevents this. It's a much better idea to add this to a custom AOSP fork than to try to make traditional desktop Linux on phones happen.

> Mobile Linux distros, such as Sailfish OS, Ubuntu Touch, Nura, Mobian, DanctNIX, Droidian, Maemo Leste, Nemo Mobile, etc., are designed to empower the user to control the tech, rather than the tech being used as a means to control the user.

How do they let the user control the tech if they don't offer users a proper fine-grained run-time permission model to decide what they hand out to apps?

> the user should be empowered to modify the app’s launcher to modify how the app is executed, like in mobile Linux. If the user wants to add an environment variable to the launcher or execute an app with an option, it should not be necessary for the user to root the device and then execute complicated commands in the terminal [...]

If it makes sense to run an app in various ways, the app developers can add such functionality to their app and the app settings.

> The problem is that Android was designed as a vehicle to collect the personal information of users to feed that data to Google’s servers for its targeted advertising.

It is true that Google's services (their web services and apps) use data collection as a revenue stream. 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. 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). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.

> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.

Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.

Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.

These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.

> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.

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. 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.

If you dont need any of the above its perfectly fine to run the banking app on your single, main profile.

The basic premise, that a secured and private phone, is useful for domestic abuse victims is of course okay. It is true that protecting your privacy from abusive family members can be useful and GrapheneOS' features, which are accurately described on their own website (contrary to the linked blog post), certainly help remove threats in that regard. See : https://grapheneos.org/features . This is dependent on the specific situation, of course, (e.g. huge difference between ex-partner stalking you and a current partner you live with abusing you), because if you are forced to give your phone password at the threat of being hurt, a secure phone won't really help you a lot.

While the licenses that GrapheneOS uses permit companies to establishes businesses using GrapheneOS software, it's not recommended by the project to buy pre-installed phones, certainly not pre-configured phones, like PrivacyPros offers. The install process of GrapheneOS is simple if you are using the WebInstaller, and there is a lot of free support available in the community chat rooms and fora if you bump into issues. This saves you a lot of money because you can buy a new, used or refurbished Pixel with the stock OS installed at a much lower price. If you install GrapheneOS itself the guide also mentions you have to verify the integrity of your installation. That also holds true for preinstalled phones, you should check the verified boot hash and set up Auditor app. Preconfigured phones should actually be completely factory reset, not only from the OS but preferably also from recovery mode and then set up again, with a check of the boot hash and a set up of Auditor app before you install any apps or start changing settings. You don't know what PrivacyPros has changed to the settings, what they loaded on the device and Auditor should be set up by yourself and straight from the beginning, before you start using the device, because pinning-based security is an important part of its security model and you would want to be pinned to a clean state from the post install.

The blog post and also the PrivacyPros website where they promote and sell their phones is riddled with unnecessary misguided advice and also falsehoods about what GrapheneOS offers and what the dangers of the stock Pixel OS and Android in general are. Pixel OS and Android in general are portrayed way too negatively. I'll just give a few examples because it will cost me way too much time too debunk and correct all of it. These ones are verified easily by yourself and I hope it just makes clear you can discard everything PrivacyPros has written and makes clear you should just consult the official GrapheneOS website. So, they pretend as if Android and Pixels themselves don't have a permission model, multiple users and verified boot. This is untrue. GrapheneOS hardens the app sandbox and permissions model more and offers stuff like storage scopes to work around to broad permissions, but the sandbox and permissions model itself exists for Android in general. Verified boot is also a standard Android feature, and also exists on iPhones and even on MacOS and ChromeOS. Multiple users are part of Android, GrapheneOS just increases the available number of users and increases their usability. Also note that users don't improve sandboxing. Sandboxing and access control exist within profiles as well, profiles are mainly meant for increased isolation via separate user data, user settings and VPN slots. They also offer separate encryption keys allowing you to selectively put data at rest etc. The whole idea of a "ghost" profile and user profiles being at the centre to security and privacy is misguided. They also call about kill switches, Pixels don't have hardware kill switches and the software kill switches are just part of Android.

GrapheneOS has many exploit mitigations and those that would break compatability with too much apps are opt-in instead of opt-out. They also have per app toggles so you can decide to use them per app. So they certainly don't sacrifice accessibility for the highest level of security.

> GrapheneOS promises to liberate us from the enshittification of Google's anticompetitive moat

This isn't something GrapheneOS promises anywhere on their website. They aim to offer a secure and private OS with good compatability with Android apps.

> but it focuses that effort exclusively on security.

They focus on privacy and usability as well. Security is actually only focused on because the privacy features aren't enforceable without security.

> Why is that constantly treated as an unreasonable fantasy?

Because tinkering, hackability and unrestricted freedom aren't the purposes for which GrapheneOS was made.

Note that this is just one example, there are also other problems with traditional desktop OSes and a large portion of desktop hardware.

It has nothing to do with devices. It has to do with OSes, most notably OSes certified by Google, which GrapheneOS isn't.

Also, it will be possible to bypass it even on certified OSes.