I received several dozen comments to my previous article, "Will Linux phones become a viable alternative to the Android/iOS duopoly?" (https://news.ycombinator.com/item?id=50051530), asking why bother developing mobile Linux when we already have a mobile Linux operating system available with the Android Open Source Project (AOSP). They argued that there is no reason to develop another mobile Linux OS, when we already can use the most popular one available, and it gives us access to millions of apps.
In this blog article, I go through the reasons why the community would struggle to fork AOSP or even add changes to each new AOSP release from Google that empowers users and maintains their freedom like mobile Linux. Here is the central argument:
> Given how Maemo Leste and UBports have struggled to maintain the large codebases developed by Nokia and Canonical, respectively, it is not realistic to expect that the community can fork an enormous project like AOSP with 309 million lines of code. Even if the AOSP fork can be rebased every year on each new AOSP release by Google, it will still be a huge amount of work to keep refactoring the code each year so the AOSP fork respects and empowers the user like mobile Linux does. If Google ever stops releasing AOSP, there is virtually no way that the community will be able to replicate all the code changes that Google is making with each new version of Android, so the community fork will diverge over time from Google’s version. As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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?
Not only do I appreciate Purism's upstream-first policy when developing its software, I also appreciate the fact that its developers take the time to answer people's questions. Purism charges high prices, but I think the company is worth supporting.
Purism's public reputation was blackened by its decision to stop repaying the refunds to people who canceled their Librem 5 pre-orders after Feb. 2020. I think that decision allowed the company to finish developing the Librem 5 phone and start shipping it in Nov. 2020, but you will find a lot of negative comments online about the company (see Reddit's r/Purism). I often point out the positive aspects about the company, because the company gave a lot to the community by developing libadwaita and Phosh, but some people don't see it that way.
I received several dozen comments to my previous article, "Will Linux phones become a viable alternative to the Android/iOS duopoly?" (https://news.ycombinator.com/item?id=50051530), asking why bother developing mobile Linux when we already have a mobile Linux operating system available with the Android Open Source Project (AOSP). They argued that there is no reason to develop another mobile Linux OS, when we already can use the most popular one available, and it gives us access to millions of apps.
In this blog article, I go through the reasons why the community would struggle to fork AOSP or even add changes to each new AOSP release from Google that empowers users and maintains their freedom like mobile Linux. Here is the central argument:
> Given how Maemo Leste and UBports have struggled to maintain the large codebases developed by Nokia and Canonical, respectively, it is not realistic to expect that the community can fork an enormous project like AOSP with 309 million lines of code. Even if the AOSP fork can be rebased every year on each new AOSP release by Google, it will still be a huge amount of work to keep refactoring the code each year so the AOSP fork respects and empowers the user like mobile Linux does. If Google ever stops releasing AOSP, there is virtually no way that the community will be able to replicate all the code changes that Google is making with each new version of Android, so the community fork will diverge over time from Google’s version. As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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?
That was a good read, and my respect for Purism increased a bit. (I say "a bit" because I knew very little about it before.)
Not only do I appreciate Purism's upstream-first policy when developing its software, I also appreciate the fact that its developers take the time to answer people's questions. Purism charges high prices, but I think the company is worth supporting.
Purism's public reputation was blackened by its decision to stop repaying the refunds to people who canceled their Librem 5 pre-orders after Feb. 2020. I think that decision allowed the company to finish developing the Librem 5 phone and start shipping it in Nov. 2020, but you will find a lot of negative comments online about the company (see Reddit's r/Purism). I often point out the positive aspects about the company, because the company gave a lot to the community by developing libadwaita and Phosh, but some people don't see it that way.