[2 of 5]
> 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.
> 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.