<noinclude>__NOINDEX__</noinclude>
<div class="scroll-table">
{| class="wikitable" style="background-color: #fff;text-align: center"

!
! Most iPhone / Android devices <ref name="most-mobile">
Most iPhone / Android phones that are sold by mobile carriers or manufacturers have locked bootloaders. These phones are often packaged with spyware installed by default, which cannot be removed. There may be rare exceptions to this rule, hence "most" and not "all". These exceptions are not the point which shall be made in this comparison. See the "Libre Android" column for what is theoretically possible.
</ref>
! "Libre Android" <ref>
There is no "Libre Android" at time of writing. It's only a concept to illustrate a point. There is no "perfect" Android distribution. GrapheneOS has verified boot but [https://archive.ph/2sYur root access is refused in default builds]. Replicant allows root access, but no references were found that Replicant makes use of verified boot yet. It's not relevant to pick any specific Android distribution for the sake of making the point "iPhone and Android Level Security for Linux Desktop Distributions" no specific Android distribution was chosen for this compassion. A "perfect" Android distribution checking all "green yes" is possible in theory. It doesn't exist due to policy decisions. (GrapheneOS vs root in default builds vs device selection / features.) There are no technical reasons for non-existence. See also this [[Mobile_Operating_System_Comparison|Overview of Mobile Projects, that focus on either/and/or security, privacy, anonymity, source-available, Freedom Software.]].
</ref>
! Linux Desktop Distributions
! {{project_name_short}} Development Goals
|-

! Upgrades do not require vendor
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! User freedom to replace operating system
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}

|-
! Administrator capabilities (root) not refused
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Custom operating system (bootloader unlock) not refused
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}

|-
! No trouble or void device warranty from software changes (rooting or bootloader unlock)
| {{No}} <ref>
https://www.howtogeek.com/240417/does-rooting-or-unlocking-void-your-android-phones-warranty/
</ref>
| {{No}} <ref name="hardware-limitation"/>
| {{Yes}}
| {{Yes}}
|-

! No user freedom restrictions
| {{No}} <ref>
[[Miscellaneous_Threats_to_User_Freedom#mobile_devices_restrictions|Mobile Devices Restrictions]]
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}

|-
! No backdoors included
| {{No}} <ref>
[[Mobile_Phone_Security#Mobile_Devices_Backdoors_in_Most_Phones_Tablets_Etc|Mobile Devices Backdoors in Most Phones Tablets Etc]]
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! No spyware included in operating system
| {{No}} <ref>
[[Mobile_Phone_Security#Data_Harvesting_by_Most_Phones|Data Harvesting by Most Phones]]
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}

|-
! No culture of freemium applications that spy on users in appstores
| {{No}} <ref>
[[Mobile_Phone_Security#Data_Harvesting_by_Most_Apps|Data Harvesting by Most Apps]]
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Culture of [[Freedom Software]] in appstores
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}

|-
! Freedom Software
| {{No}} <ref>Comes with a lot proprietary software installed by default.</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}

|-
! Compromised application cannot access data of other applications
| {{Yes}} <ref name="exploitedapp">
That would require an exploit.

In comparison, a compromised application on the Linux desktop running under <code>user</code> has full access to all information which that user has access to, including all files, keystrokes and so on. The exception is when [https://en.wikipedia.org/wiki/Mandatory_access_control mandatory access control (MAC)] is in use and successfully confines that application.
</ref>
| {{Yes}} <ref name="exploitedapp"/>
| {{No}}
| {{Yes}}
|-

! [[Malware_and_Firmware_Trojans#Malware|Malware]] on a compromised system cannot easily gain root
| {{Yes}} <ref name="malware-gain-root">
Occasionally there are exploits that allow applications to gain root, but as time passes more of these vulnerabilities are being fixed.
</ref>
| {{Yes}} <ref name="malware-gain-root"/>
| {{No}} <ref>
On the Linux desktop the process of Preventing [[Malware and Firmware Trojans|malware]] from [[Root#Prevent_Malware_from_Sniffing_the_Root_Password|Sniffing the Root Password]] is cumbersome and unpopular. Therefore any compromised application on the Linux desktop could lead to root compromise. This in turn might compromise the bootloader, kernel, or even hardware. It is difficult to detect [[Malware and Firmware Trojans|malware]], remove a [https://en.wikipedia.org/wiki/Rootkit rootkit] and [[Malware and Firmware Trojans#Valid_Compromise_Indicators_versus_Invalid_Compromise_Indicators|indicators of compromise are rare]].
</ref>
| {{Yes}}
|-

! Reasonable resistance against system wide rootkit
| {{Yes}} <ref name="verifiedboot">Through verified boot.</ref>
| {{Yes}} <ref name="verifiedboot"/>
| {{No}}
| {{Yes}}

|-
! [[Verified_Boot#Hash_Check_all_Files_at_Boot|Verified Boot]]
| {{Yes}}
| {{Yes}}
| {{No}}
| {{Yes}}
|-

! [https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598 Hardened Kernel]
| {{Yes}}
| {{Yes}}
| some
| {{Yes}}

|-
! [https://github.com/roddhjav/apparmor.d Full System MAC Policy]
| {{Yes}}
| {{Yes}}
| {{No}}
| {{Yes}}
|-

! Internal storage can reasonably easily be removed and mounted elsewhere for the purpose of data recovery or hunting malware / rootkits.
| {{No}} <ref>
* [[Android#How_Android_Blocks_Effective_Malware_Analysis|How Android Blocks Effective Malware Analysis]]
* [[Android#How_Android_Prevents_Full_Device_Backups|How Android Prevents Full Device Backups]]
</ref>
| {{No}} <ref name="hardware-limitation">Same issue as Most iPhone / Android devices since inheriting the same hardware limitations.</ref>
| {{Yes}} <ref>
Computer (non-mobile) hardware is much more flexible. Storage devices can be removed from a computer, then added to another computer as a secondary disk. When booting from an installation assumed to be uncompromised (by [the same] malware), a search for malware can be performed on the other disk without executing any code, reducing risk of infection for the booted disk. This kind of procedure can be performed reasonably easily by most repair shops, and even non-technical people can do this without the need for soldering.
</ref>
| {{Yes}} <ref name="same-as-linux-desktop">Same as Linux Desktop Distributions.</ref>
|-

! Internal storage can reasonably easily be decrypted once transferred to a different device if password is known.
| {{No}} <ref>
[[Android#Limitations_on_Encryption_Key_Backups|Limitations on Encryption Key Backups]]
</ref>
| {{No}} <ref>Same issue as Most iPhone / Android devices. Limitation of hardware, not software.</ref>
| {{Yes}}
| {{Yes}} <ref>Same as Linux Desktop Distributions.</ref>
|-

! Can reasonably easily boot from external hard drive, ignoring internal harddrive for purpose of data recovery or hunting malware / rootkits.
| {{No}}
| {{No}} <ref name="hardware-limitation"/>
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>

|-
! Can reasonably easily create full data backup.
| {{No}} <ref>See next point below.</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! Can reasonably easily create full data backup of any app when device is rooted with Titanium Backup or similar
| {{No}} <ref>
[https://signal.org Signal messenger app] is such an example. People expected [https://www.titaniumtrack.com/titanium-backup.html Titanium Backup] to be able to backup the Signal app data but [https://github.com/signalapp/Signal-Android/issues/8130#issuecomment-414780981 lost data]. [https://community.signalusers.org/t/howto-manual-backup-restore-if-full-backup-does-not-work/2462/print Extra steps are required for a Signal backup.] (Instructions untested by author of this wiki page.)
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! Applications cannot refuse data backup (for purpose of malware, spyware analysis or backup and restore).
| {{No}} <ref>
Quote https://developer.android.com/guide/topics/manifest/application-element#allowbackup

<code>android:allowBackup</code>

<blockquote>
Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.
</blockquote>
</ref>
| {{Yes}}
| {{Yes}} <ref name="fullaccess"/>
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! No culture of users can ask device (code) for permission and device (code) will decide to grant or refuse the request.
| {{No}}
| {{Yes}}
| {{Yes}} <ref name="fullaccess">If credentials can be provided (full disk encryption password if used), (super) root will have full access.</ref>
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! No culture of applications refusing to run if device is rooted.
| {{No}} <ref>
[https://android.stackexchange.com/questions/29359/how-to-prevent-applications-from-discovering-my-phone-as-being-rooted How to prevent applications from discovering my phone as being Rooted]
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! No culture of applications refusing to run if using a custom operating system (custom ROM).
| {{No}} <ref>
[https://www.howtogeek.com/241012/safetynet-explained-why-android-pay-and-other-apps-dont-work-on-rooted-devices/ How-To Geek: SafetyNet Explained: Why Android Pay and Other Apps Don’t Work on Rooted Devices]
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! User (privacy) settings are respected.
| {{No}} <ref>
[https://apnews.com/828aefab64d4411bac257a07c1af0ecb/AP-Exclusive:-Google-tracks-your-movements,-like-it-or-not AP Exclusive: Google tracks your movements, like it or not]

<blockquote>Google wants to know where you go so badly that it records your movements even when you explicitly tell it not to.

An Associated Press investigation found that many Google services on Android devices and iPhones store your location data even if you’ve used a privacy setting that says it will prevent Google from doing so.

Computer-science researchers at Princeton confirmed these findings at the AP’s request.</blockquote></ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! WiFi off indicator means that WiFi is really off.
| {{No}} <ref>
* [https://qz.com/1169760/phone-data/ Google can still use Bluetooth to track your Android phone when Bluetooth is turned off]
* [https://www.zdnet.com/article/how-google-and-everyone-else-gets-wi-fi-location-data/ How Google--and everyone else--gets Wi-Fi location data]

<blockquote>How it works, according to Google, is that the Android Location Services periodically checks on your location using GPS, Cell-ID, and Wi-Fi to locate your device. When it does this, your Android phone will send back publicly broadcast Wi-Fi access points' Service set identifier (SSID) and Media Access Control (MAC) data. Again, this isn't just how Google does it; it's how everyone does it. It's Industry practice for location database vendors.</blockquote>
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! Bluetooth off indicator means that Bluetooth is really off.
| {{No}} <ref>[https://qz.com/1169760/phone-data/ Google can still use Bluetooth to track your Android phone when Bluetooth is turned off]</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>

|-
! Prevention of targeted malicious upgrades. <ref>
As in singling out specific users. Shipping malicious upgrades to select users only.
</ref>
| {{No}} <ref name="targeted-updates">
[[Android#Vulnerability_to_Target_Malicious_Upgrades|Vulnerability to Target Malicious Upgrades]]
</ref>
| ? <ref>
Probably same as Linux Desktop Distributions.
</ref>
| ? <ref>
Linux distributions usually do not require an e-mail based login to receive upgrades. Users can still be singled out by IP addresses unless users opt-in for using something such as apt-transport-tor which is not the default.
</ref>
| {{Yes}} <ref>
All upgrades are downloaded over Tor. There is no way for the server to ship legit upgrade packages to most users while singling out specific users for targeted attacks.
</ref>
|-

! Vendors do not sometimes introduce mitigations that introduce attack surface.
| {{No}} <ref>
Some Android vendors [https://googleprojectzero.blogspot.com/2020/02/mitigations-are-attack-surface-too.html introduce mitigations that introduce attack surface].
</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

! The GNU Project does not state: "[https://www.gnu.org/proprietary/malware-apple.html Apple's Operating Systems Are Malware]" and "[https://www.gnu.org/proprietary/malware-google.html Google's Software is Malware]".
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}} <ref name="same-as-linux-desktop"/>
|-

|}
</div>

Quote [https://www.theregister.com/2020/03/06/1_billion_vulnerable_android_devices_which/ More than a billion hopelessly vulnerable Android gizmos in the wild that no longer receive security updates – research]. The operating system of these devices:

* Do not receive security upgrades from the vendor.
* Third parties (such as users or the modding community) cannot provide (security) upgrades either due to locked bootloaders, which cannot be unlocked due to vendor decision and due to unavailability of a security bug which could unlock the bootloader.
* Even if bootloaders can be unlocked there might not be an adequate operating system upgrades available from third parties, such as the modding community. Either due to unpopularity of the devices among modding developers and/or due to technical challenges.

Ability to upgrade (security fixes) devices; replace operating system; bootloader freedom vs bootloader non-freedom:

* iPhones and some Android devices have locked boot loaders that cannot be unlocked. This restricts user freedom and makes replacing the operating system impossible without a verified boot bypass exploit. In case the vendor deprecated security support for the device, the only choices users realistically have is to keep using an insecure device, or to buy a device which still has security support. Similarly, locked bootloaders also prevent gaining administrator (root) access.
* Some Android devices do allow unlocking the bootloader but not with custom verified boot keys, causing a decrease in security.
* Some Android devices (such as the Nexus or Pixel devices) support full verified boot with custom keys that can be used with alternative operating systems.

In conclusion, when using iPhone/Android devices that still receive security updates, the iPhone/Android approach provides strong protection against malware, meaning those platforms are impacted much less than Windows or Linux desktops. <ref name="exploitedapp"/> Despite the many downsides ([[Mobile_Phone_Security#Mobile_Devices_Backdoors_in_Most_Phones_Tablets_Etc|Mobile Devices Backdoors in Most Phones Tablets Etc]], [[Mobile_Phone_Security#Data_Harvesting_by_Most_Phones|Data Harvesting by Most Phones]], ...), the security model of popular mobile operating systems often affords better protection when attempting to prevent any malicious and unapproved party from establishing a foothold in their ecosystem. In the process, the user's and the security community's ability to audit and control what their devices are actually doing is severely diminished. Due to a [[Miscellaneous_Threats_to_User_Freedom#Conflict_of_Interest|Conflict of Interest]] this comes at the expense of transferring power from the user to the developers, user freedom restrictions, [[Miscellaneous_Threats_to_User_Freedom#Freedom_vs_Tyrant_Security|Tyrant Security]], [[Miscellaneous_Threats_to_User_Freedom#War_on_General_Purpose_Computing|War on General Purpose Computing]].<noinclude>
{{Header}}
= Footnotes =
<references/>
{{Footer}}
</noinclude>