Mobile Operating System Comparison
This mobile operating system comparison focused on either/and/or security, privacy, anonymity,
source-available, Freedom Software, de-googled, un-googled mobile operating systems. Also other popular or frequently discussed operating systems might be added.
source-available - better term required
- can be modified and redistributed
- source available to public without registration
- a legal condition preventing the usual blessing of capitalized Open Source, Free Software as blessed by stewards OSI, FSF or Debian DSFG licenses
iPhone and Android
|Most iPhone / Android devices ||"Libre Android" ||Linux Desktop Distributions||Kicksecure ™ 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 ||No ||Yes||Yes|
|No user freedom restrictions||No||Yes||Yes||Yes|
|No spyware included in operating system||No ||Yes||Yes||Yes|
|No culture of freemium applications that spy on users in appstores||No||Yes||Yes||Yes|
|Culture of Freedom Software in appstores||No||Yes||Yes||Yes|
|Freedom Software||No ||Yes||Yes||Yes|
|Compromised application cannot access data of other applications||Yes ||Yes ||No||Yes|
|Malware on a compromised system cannot easily gain root||Yes ||Yes ||No ||Yes|
|Reasonable resistance against system wide rootkit||Yes ||Yes ||No||Yes|
|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 ||No ||Yes ||Yes |
|Internal storage can reasonably easily be decrypted once transferred to a different device if password is known.||No ||No ||Yes||Yes |
|Can reasonably easily boot from external hard drive, ignoring internal harddrive for purpose of data recovery or hunting malware / rootkits.||No||No ||Yes||Yes |
|Can reasonably easily create full data backup.||No ||Yes||Yes||Yes 
|Can reasonably easily create full data backup of any app when device is rooted with Titanium Backup or similar||No ||Yes||Yes||Yes |
|Applications cannot refuse data backup (for purpose of malware, spyware analysis or backup and restore).||No ||Yes||Yes ||Yes |
|No culture of users can ask device (code) for permission and device (code) will decide to grant or refuse the request.||No||Yes||Yes ||Yes |
|No culture of applications refusing to run if device is rooted.||No ||Yes||Yes||Yes |
|No culture of applications refusing to run if using a custom operating system (custom ROM).||No ||Yes||Yes||Yes |
|User (privacy) settings are respected.||No ||Yes||Yes||Yes |
|WiFi off indicator means that WiFi is really off.||No ||Yes||Yes||Yes |
|Bluetooth off indicator means that Bluetooth is really off.||No ||Yes||Yes||Yes |
|Prevention of targeted malicious upgrades. ||No ||? ||? ||Yes |
|Vendors do not sometimes introduce mitigations that introduce attack surface.||No ||Yes||Yes||Yes |
|The GNU Project does not state: "Apple's Operating Systems Are Malware" and "Google's Software is Malware".||No||Yes||Yes||Yes |
Quote 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.  Despite the many downsides, 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 Conflict of Interest this comes at the expense of transferring power from the user to the developers, user freedom restrictions, Tyrant Security, War on General Purpose Computing.
This applies to almost all users of Android. 
- Personal information: Name, email address, and telephone number.
- Device-specific information: Hardware model, operating system, unique device identifiers, mobile network information.
- Log information: Search queries, telephony log information (phone number, calling-party number, forwarding numbers, time and date of calls, duration of calls, SMS routing information and types of calls), IP address, browser-specific cookies, and device event information (crashes, system activity, hardware settings, browser type, browser language, the date and time of your request and referral URL).
- Location information: IP address, GPS, and other sensors providing information on nearby services such as Wi-Fi access points and cell towers. It was recently discovered Google continues to track users even after they opt-out of Location History. 
- Unique application numbers: Information on application types and version numbers.
- Local storage: Storing personal information locally with local browser storage (like HTML5) and application data caches.
- Slogan: "Privacy by Design"
- A project from the Calyx Institute, New York, a "non-profit education and research organization"
- Free and Open Source Software -> https://gitlab.com/calyxos
- Uses microG for implementing Google's proprietary services
- Hardware: Google Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL, Pixel 3a, Pixel 3a XL
- Nonfreedom software, i.e. not Freedom Software 
source-available (can be modified and redistributed) (You may not use the source code for commercial purposes.)source only available under specific registration / agreements.
- Security focused Android
- Common ancestry with GrapheneOS.
- (Being discussed by Tor Project as well: https://blog.torproject.org/mission-improbable-hardening-android-security-and-privacy)
- Using the Tor Project Copperhead version requires patience and technical skills
- Probably not suitable for average daily usage
- Freedom restricted by software vendor: root access refused!
- su is only available in user debug builds, so very few users are actually capable of obtaining root on their own devices.
- detail discussion
- Hardware: Google Pixel Series phones including, Pixel 1, 2, 3, 3a and all XL models.
- Community Initiatives:
- Hardened version of AOSP, with a strong focus on security and privacy. Currently only supported on Pixel devices.
- By Daniel Micay (who previously worked on CopperheadOS).
- Common ancestry with CopperheadOS.
- Freedom Software? -> https://github.com/GrapheneOS/os_issue_tracker/issues/109
- Prioritizes power of developers: Yes.
- Prioritizes power of users: No.
- Implements various changes to harden libc, the Linux kernel, and other OS components.
- Includes Vanadium, a hardened and mostly de-Googled version of Chromium.
- Allows users to disable network and sensor (accelerometer, etc.) access for apps.
- Argues that allowing users to gain root (superuser) access would inevitably break the security model and that there is no conceivable solution that can uphold both user security and freedom.
- Quote GrapheneOS lead developer:
GrapheneOS is not aimed at power users or hobbyists aiming to tinker with their devices more than they can via the stock OS or AOSP.
- Making efforts to allow users to gain root in a secure way: No.
- Supports DRM (Digital Restrictions Management) / walled garden / anti-freedom / Google SafetyNet where developers can configure their applications to only run on devices on certified firmware. 
- Quote GrapheneOS lead developer:
Users are free to avoid apps using attestation to implement DRM / anti-cheat.
- More and more businesses communicate over proprietary messengers such as WhatsApp and WhatsApp cannot be used on rooted devices or with custom ROMs. 
- More and more government services require the same. For example, an Android or iPhone with Google maps location history enabled and Skype is mandatory for entering Japan.  Google maps is produced by Google and Skype produced by Microsoft are among the worst privacy-intrusive companies.
- Many people would loose their job if they decided not to use for example WhatsApp since many companies internally use WhatsApp.
- Three are still 2 billion unbanked people.  People who do not even have access to the most basic financial services such as a bank account. For unbanked people it would be unreasonable and should not be expected of them to refuse their first chance to use a mobile banking app with such restrictions.
- In conclusion, the recommendation to simply not use such applications is impractical and counter the lived reality of many people.
- Potential Conflict of Interest. If GrapheneOS wouldn't disable easy to use technical ways that most laymen users can use to gain root and/or to keep control over the software running on their devices, then GrapheneOS's chances to be ever get a highly profitable hardware producer partnership would be severely diminished.
- Quote GrapheneOS lead developer:
- Full verified boot which would be great if the key would be held by users and encouraged through a first start process or similar instead of held by the developer.
- New project in development
- Open source as much as possible
- Story: https://www.indidea.org/gael/blog/leaving-apple-google-eelo-odyssey-part1-mobile-os
- Hardware: LeEco Le2, Xiaomi Mi 5S, (LG G6)
- Hardware: Fairphone 1, Fairphone 2
- Successfully crowdfunded, will be delivered (stage: pre-order)
- PureOS, based on Debian and others
- Hardware: Librem 5
- Hardware Security: CPU separate from Baseband Processor, Physical Kill Switches for Camera, Microphone, WiFi/Bluetooth, and Baseband, with additional kill switches planned for the cellular (SIM) card slot and the GPS receiver.
- ARM TrustZone (similar to Intel ME) vs Librem5 Security
- Previously called Cyanogenmod
- No google services installed by default (good for privacy and security).
- Google services can be optionally installed as an add-on
- Hardware: after market firmware for loads of devices, including Fairphone and OnePlus
- Open platform (OpenPhoenux GTA04) in tradition of Openmoko
- Hardware: Neo900
- Not all Freedom Software by default but software modifications permitted
- Hardware that grants users the "right to flash"
- (Root and custom ROM allowed without voiding warranty)
- Hardware: OnePlus 3, 3T, 5, 5T (current models)
- Modular smartphone for Raspberry Pi
- Currently crowdfunding, delivery aimed for march 2018
- Open hardware and software; security/privacy focus obscure
- Hardware: Rapsberry Pi zero, Pi 2 and Pi 3; 3.2″ (external antenna), 4″ and 5″ LCDs
- By KDE
- Not security focused at all at this stage?
- Builds based on Kubuntu and Archlinux
- Hardware: Google Nexus 5, 5X
- Very early stage of development
- Linux distro (based on Alpine Linux) on the phone
- Hardware: many devices, including Google Nexus models and Fairphone 2
- Strict Freedom Software focus
- No binary blobs
- Hardware: very bad support, mostly older Samsung Galaxy models
- Since the internal WiFi card requires binary blob, external USB WiFi dongle is required
- Apart from the drivers, the OS itself is Freedom Software
- Hardware: Fairphone 2, OnePlus One, Nexus 5, BQ Aquaris M10 FHD (tablet)
Hardware Kill Switches
No phone has a speaker yet that can be disabled but this is just as important as speakers can be turned into microphones. That is because a speaker is technically quite similar to microphones. See SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit.
Next best option is to have a phone that at least has a removable battery to make it's sometimes really powered off and not secretly spying.
- 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.
- 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 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 Overview of Mobile Projects, that focus on either/and/or security, privacy, anonymity, source-available, Freedom Software..
- Same issue as Most iPhone / Android devices since inheriting the same hardware limitations.
- One example is Carrier IQ.
- Comes with a lot proprietary software installed by default.
That would require an exploit.
In comparison, a compromised application on the Linux desktop running under
userhas full access to all information which that user has access to, including all files, keystrokes and so on. The exception is when mandatory access control (MAC) is in use and successfully confines that application.
- Occasionally there are exploits that allow applications to gain root, but as time passes more of these vulnerabilities are being fixed.
- On the Linux desktop the process of Preventing malware from 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, remove a rootkit and indicators of compromise are rare.
- Through verified boot.
This is a hardware limitation. Internal storage is a chip and soldered. Removal is an operation which most repair shops are incapable of performing. Even if removed, it's not easy to find a device which can read the device without booting from it. Perhaps it could be booted from in another device, but that would be beside the point. If the operating system is unbootable due to software issues, it will also be unbootable elsewhere. If malware analysis is the goal, then no code from the suspected infected storage device should ever be executed.
Even worse if full disk encryption was used as per next table entry.
Quote How to fully backup non-rooted devices?:
For 4.0+ devices there is a solution called "adb backup".
Note: This only works for apps that do not disallow backup! Apps that disallow backup are simply ignored when creating a backup using this way.
Information from Copy full disk image from Android to computer does not work for non-rooted / non-rootable devices.
Taking a non-rooted Android device with GrapheneOS, contributed by a user.
$ adb devices List of devices attached xxxxxxxxxxx device $ adb root adbd cannot run as root in production builds $ adb shell walleye:/ $ ls ls: ./init.zygote64_32.rc: Permission denied ls: ./init.rc: Permission denied ls: ./init.usb.rc: Permission denied ls: ./ueventd.rc: Permission denied ls: ./init.zygote32.rc: Permission denied ls: ./init: Permission denied ls: ./cache: Permission denied ls: ./init.environ.rc: Permission denied ls: ./persist: Permission denied ls: ./postinstall: Permission denied ls: ./init.usb.configfs.rc: Permission denied ls: ./metadata: Permission denied acct apex bin bugreports charger config d data debug_ramdisk default.prop dev dsp etc firmware lost+found mnt odm oem proc product product_services res sbin sdcard storage sys system vendor 1|walleye:/ $ sudo ls /system/bin/sh: sudo: inaccessible or not found 127|walleye:/ $ su /system/bin/sh: su: inaccessible or not found 127|walleye:/ $
walleye:/dev/block $ ls -lah total 0 drwxr-xr-x 6 root root 2.4K 1970-07-03 11:40 . drwxr-xr-x 18 root root 3.9K 2020-05-26 15:41 .. lrwxrwxrwx 1 root root 37 1970-07-03 11:40 bootdevice -> /dev/block/platform/soc/1da4000.ufshc drwxr-xr-x 2 root root 1.6K 1970-07-03 11:40 by-name brw------- 1 root root 252, 0 1970-07-03 11:40 dm-0 brw------- 1 root root 252, 1 1970-07-03 11:40 dm-1 brw------- 1 root root 7, 0 1970-07-03 11:40 loop0 brw------- 1 root root 7, 8 1970-07-03 11:40 loop1 brw------- 1 root root 7, 80 1970-07-03 11:40 loop10 brw------- 1 root root 7, 88 1970-07-03 11:40 loop11 brw------- 1 root root 7, 96 1970-07-03 11:40 loop12 brw------- 1 root root 7, 104 1970-07-03 11:40 loop13 brw------- 1 root root 7, 112 1970-07-03 11:40 loop14 brw------- 1 root root 7, 120 1970-07-03 11:40 loop15 brw------- 1 root root 7, 16 1970-07-03 11:40 loop2 brw------- 1 root root 7, 24 1970-07-03 11:40 loop3 brw------- 1 root root 7, 32 1970-07-03 11:40 loop4 brw------- 1 root root 7, 40 1970-07-03 11:40 loop5 brw------- 1 root root 7, 48 1970-07-03 11:40 loop6 brw------- 1 root root 7, 56 1970-07-03 11:40 loop7 brw------- 1 root root 7, 64 1970-07-03 11:40 loop8 brw------- 1 root root 7, 72 1970-07-03 11:40 loop9 drwxr-xr-x 2 root root 80 1970-07-03 11:40 mapper drwxr-xr-x 3 root root 60 1970-07-03 11:40 platform brw------- 1 root root 1, 0 1970-07-03 11:40 ram0 brw------- 1 root root 1, 1 1970-07-03 11:40 ram1 brw------- 1 root root 1, 10 1970-07-03 11:40 ram10 brw------- 1 root root 1, 11 1970-07-03 11:40 ram11 brw------- 1 root root 1, 12 1970-07-03 11:40 ram12 brw------- 1 root root 1, 13 1970-07-03 11:40 ram13 brw------- 1 root root 1, 14 1970-07-03 11:40 ram14 brw------- 1 root root 1, 15 1970-07-03 11:40 ram15 brw------- 1 root root 1, 2 1970-07-03 11:40 ram2 brw------- 1 root root 1, 3 1970-07-03 11:40 ram3 brw------- 1 root root 1, 4 1970-07-03 11:40 ram4 brw------- 1 root root 1, 5 1970-07-03 11:40 ram5 brw------- 1 root root 1, 6 1970-07-03 11:40 ram6 brw------- 1 root root 1, 7 1970-07-03 11:40 ram7 brw------- 1 root root 1, 8 1970-07-03 11:40 ram8 brw------- 1 root root 1, 9 1970-07-03 11:40 ram9 brw------- 1 root root 8, 0 1970-07-03 11:40 sda brw------- 1 root root 8, 1 1970-07-03 11:40 sda1 brw------- 1 root root 8, 10 1970-07-03 11:40 sda10 brw------- 1 root root 8, 11 1970-07-03 11:40 sda11 brw------- 1 root root 8, 12 1970-07-03 11:40 sda12 brw------- 1 root root 8, 13 1970-07-03 11:40 sda13 brw------- 1 root root 8, 14 1970-07-03 11:40 sda14 brw------- 1 root root 8, 15 1970-07-03 11:40 sda15 brw------- 1 root root 259, 0 1970-07-03 11:40 sda16 brw------- 1 root root 259, 1 1970-07-03 11:40 sda17 brw------- 1 root root 259, 2 1970-07-03 11:40 sda18 brw------- 1 root root 259, 3 1970-07-03 11:40 sda19 brw------- 1 root root 8, 2 1970-07-03 11:40 sda2 brw------- 1 root root 259, 4 1970-07-03 11:40 sda20 brw------- 1 root root 259, 5 1970-07-03 11:40 sda21 brw------- 1 root root 259, 6 1970-07-03 11:40 sda22 brw------- 1 root root 259, 7 1970-07-03 11:40 sda23 brw------- 1 root root 259, 8 1970-07-03 11:40 sda24 brw------- 1 root root 259, 9 1970-07-03 11:40 sda25 brw------- 1 root root 259, 10 1970-07-03 11:40 sda26 brw------- 1 root root 259, 11 1970-07-03 11:40 sda27 brw------- 1 root root 259, 12 1970-07-03 11:40 sda28 brw------- 1 root root 259, 13 1970-07-03 11:40 sda29 brw------- 1 root root 8, 3 1970-07-03 11:40 sda3 brw------- 1 root root 259, 14 1970-07-03 11:40 sda30 brw------- 1 root root 259, 15 1970-07-03 11:40 sda31 brw------- 1 root root 259, 16 1970-07-03 11:40 sda32 brw------- 1 root root 259, 17 1970-07-03 11:40 sda33 brw------- 1 root root 259, 18 1970-07-03 11:40 sda34 brw------- 1 root root 259, 19 1970-07-03 11:40 sda35 brw------- 1 root root 259, 20 1970-07-03 11:40 sda36 brw------- 1 root root 259, 21 1970-07-03 11:40 sda37 brw------- 1 root root 259, 22 1970-07-03 11:40 sda38 brw------- 1 root root 259, 23 1970-07-03 11:40 sda39 brw------- 1 root root 8, 4 1970-07-03 11:40 sda4 brw------- 1 root root 259, 24 1970-07-03 11:40 sda40 brw------- 1 root root 259, 25 1970-07-03 11:40 sda41 brw------- 1 root root 259, 26 1970-07-03 11:40 sda42 brw------- 1 root root 259, 27 1970-07-03 11:40 sda43 brw------- 1 root root 259, 28 1970-07-03 11:40 sda44 brw------- 1 root root 259, 29 1970-07-03 11:40 sda45 brw------- 1 root root 8, 5 1970-07-03 11:40 sda5 brw------- 1 root root 8, 6 1970-07-03 11:40 sda6 brw------- 1 root root 8, 7 1970-07-03 11:40 sda7 brw------- 1 root root 8, 8 1970-07-03 11:40 sda8 brw------- 1 root root 8, 9 1970-07-03 11:40 sda9 brw------- 1 root root 8, 16 1970-07-03 11:40 sdb brw------- 1 root root 8, 17 1970-07-03 11:40 sdb1 brw------- 1 root root 8, 32 1970-07-03 11:40 sdc brw------- 1 root root 8, 33 1970-07-03 11:40 sdc1 brw------- 1 root root 8, 48 1970-07-03 11:40 sdd brw------- 1 root root 8, 49 2020-05-26 15:41 sdd1 brw------- 1 root root 8, 58 1970-07-03 11:40 sdd10 brw------- 1 root root 8, 59 1970-07-03 11:40 sdd11 brw------- 1 root root 8, 60 1970-07-03 11:40 sdd12 brw------- 1 root root 8, 61 1970-07-03 11:40 sdd13 brw------- 1 root root 8, 62 1970-07-03 11:40 sdd14 brw------- 1 root root 8, 63 2020-05-26 15:42 sdd15 brw------- 1 root root 259, 30 2020-05-26 15:41 sdd16 brw------- 1 root root 259, 31 2020-05-26 15:41 sdd17 brw------- 1 root root 259, 32 1970-07-03 11:40 sdd18 brw------- 1 root root 8, 50 1970-07-03 11:40 sdd2 brw------- 1 root root 8, 51 1970-07-03 11:40 sdd3 brw-rw---- 1 system system 8, 52 2020-05-26 15:48 sdd4 brw------- 1 root root 8, 53 1970-07-03 11:40 sdd5 brw------- 1 root root 8, 54 1970-07-03 11:40 sdd6 brw------- 1 root root 8, 55 1970-07-03 11:40 sdd7 brw------- 1 root root 8, 56 1970-07-03 11:40 sdd8 brw------- 1 root root 8, 57 1970-07-03 11:40 sdd9 brw------- 1 root root 8, 64 1970-07-03 11:40 sde brw------- 1 root root 8, 65 1970-07-03 11:40 sde1 brw------- 1 root root 8, 66 1970-07-03 11:40 sde2 brw------- 1 root root 8, 67 1970-07-03 11:40 sde3 brw------- 1 root root 8, 68 1970-07-03 11:40 sde4 brw------- 1 root root 8, 69 1970-07-03 11:40 sde5 brw------- 1 root root 8, 80 1970-07-03 11:40 sdf brw------- 1 root root 8, 81 1970-07-03 11:40 sdf1 brw------- 1 root root 8, 82 1970-07-03 11:40 sdf2 brw------- 1 root root 8, 83 1970-07-03 11:40 sdf3 brw------- 1 root root 8, 84 1970-07-03 11:40 sdf4 brw------- 1 root root 8, 85 1970-07-03 11:40 sdf5 drwx------ 2 root root 40 1970-07-03 11:40 vold brw------- 1 root root 253, 0 2020-05-26 15:41 zram0
$ adb shell walleye:/ $ mount /dev/root on / type ext4 (ro,seclabel,nodev,relatime) tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1851548k,nr_inodes=462887,mode=755) devpts on /dev/pts type devpts (rw,seclabel,nosuid,noexec,relatime,mode=600) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,gid=3009,hidepid=2) sysfs on /sys type sysfs (rw,seclabel,nosuid,nodev,noexec,relatime) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) tmpfs on /mnt type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=1851548k,nr_inodes=462887,mode=755,gid=1000) tmpfs on /apex type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=1851548k,nr_inodes=462887,mode=755) /dev/block/sdd3 on /persist type ext4 (rw,seclabel,nosuid,nodev,noatime,data=ordered) /dev/block/dm-1 on /vendor type ext4 (ro,seclabel,relatime) none on /dev/cpuctl type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) none on /acct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) none on /dev/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent) none on /dev/stune type cgroup (rw,nosuid,nodev,noexec,relatime,schedtune) /dev/root on /apex/com.android.tzdata@290000000 type ext4 (ro,seclabel,relatime) /dev/root on /apex/com.android.tzdata type ext4 (ro,seclabel,relatime) /dev/root on /apex/com.android.runtime@1 type ext4 (ro,seclabel,relatime) /dev/root on /apex/com.android.runtime type ext4 (ro,seclabel,relatime) debugfs on /sys/kernel/debug type debugfs (rw,seclabel,relatime) none on /config type configfs (rw,nosuid,nodev,noexec,relatime) tracefs on /sys/kernel/debug/tracing type tracefs (rw,seclabel,relatime) /dev/block/sde4 on /metadata type ext4 (rw,sync,seclabel,nosuid,nodev,noatime,discard,data=ordered) /dev/block/sda28 on /firmware type vfat (ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro) tmpfs on /storage type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=1851548k,nr_inodes=462887,mode=755,gid=1000) /dev/block/sda45 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,resgid=1065,errors=panic,stripe=4096,data=ordered) /dev/root on /apex/com.android.conscrypt@290000000 type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.conscrypt type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.media@290000000 type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.media type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.media.swcodec@290000000 type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.media.swcodec type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.resolv@290000000 type ext4 (ro,seclabel,nodev,relatime) /dev/root on /apex/com.android.resolv type ext4 (ro,seclabel,nodev,relatime) adb on /dev/usb-ffs/adb type functionfs (rw,relatime) mtp on /dev/usb-ffs/mtp type functionfs (rw,relatime) ptp on /dev/usb-ffs/ptp type functionfs (rw,relatime) /data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid,default_normal) /data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid,default_normal) /data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid,default_normal) /data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid,default_normal) /data/media on /mnt/runtime/full/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid,default_normal) pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
- 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.
- Same as Linux Desktop Distributions.
The masterkey is not stored on the internal storage. It is stored in hardware. which is even harder to extract.
Note: "masterkey" here does not mean "backdoor". This is normal for most Linux desktop distributions offering full disk encryption. The masterkey is stored somewhere. When entering the password at boot with Linux desktop full disk encryption enabled, what gets decrypted is not actually the disk but the masterkey. This is then used to decrypt the disk, which is also called luks header. The advantage of the masterkey is that changing the disk encryption password is possible without having to re-encrypt the whole disk. (
It is perhaps possible to dump the masterkey if the phone can still be started and can be rooted. There are no instructions how to do so. Hence, not "reasonably easily".
- Same issue as Most iPhone / Android devices. Limitation of hardware, not software.
- Same as Linux Desktop Distributions.
- See next point below.
- Signal is such an example. People expected Titanium Backup to be able to backup the Signal app data but lost data. Extra steps are required for a Signal backup. (Insturctions untested by author of this wiki page.)
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.
- If credentials can be provided (full disk encryption password if used), (super) root will have full access.
- How to prevent applications from discovering my phone as being Rooted
- How-To Geek: SafetyNet Explained: Why Android Pay and Other Apps Don’t Work on Rooted Devices
AP Exclusive: Google tracks your movements, like it or not
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.
- Google can still use Bluetooth to track your Android phone when Bluetooth is turned off
- How Google--and everyone else--gets Wi-Fi location data
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.
- Google can still use Bluetooth to track your Android phone when Bluetooth is turned off
- As in singling out specific users. Shipping malicious upgrades to select users only.
- Most android phones have a feature which allows to login on google play web/desktop version using the same e-mail address which is used on the phone. Usually the same gmail address. When clicking install for an app using the google play web/desktop version, the user will be prompter (in case of having registred multiple devices) on which device the app should be installed. After pressing install, the app will be installed on the phone. This video demonstrates this. It is therefore established that the google website can result in remote app installation on the phone. It follows that a coerced or compromised google play website could do the same. Since the gmail based web login can be linked to the same gmail address on the phone, pushing targeted malicious upgrades is esspecially easy. Even if a phone was always fully torified (all traffic routed over Tor) the gmail identifier could still be used. While Tor can anonymize the connection, it does not (and should not) attempt to modify anything inside the traffic (the gmail identifier).
- Probably same as Linux Desktop Distributions.
- 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.
- 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.
- Some Android vendors introduce mitigations that introduce attack surface.
- Except to the few users using after market firmwares that resist flashing google play services. https://www.androidpit.com/android-without-google-apps
- Google's insistence on real-name policies for Gmail and Youtube accounts, along with strict measures to prevent signing up via Tor, have significantly contributed to user profiling. Google has also dropped its ban on personally-identifiable information in advertisement services.
- Meaning Google applications continue to store time-stamped location data without user input.
CopperheadOS source code for all devices are made available to the public under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license, along with some portions that are GPL2 (kernel) or GPL3 (F-Droid).
Devices purchased from our store come with a per-device commercial license for the official builds.
Contact firstname.lastname@example.org for obtaining commercial licensing for the source code, bulk sales of devices or custom development work. Funding the public release of CopperheadOS sources under more permissive licensing is also an option.
- Quote https://grapheneos.org/usage#sandboxed-play-services
The hardware attestation feature is part of the Android Open Source Project and is fully supported by GrapheneOS. SafetyNet attestation chooses to use it to enforce using Google certified operating systems. However, app developers can use it directly and permit other properly signed operating systems upholding the security model. GrapheneOS has a detailed guide for app developers on how to support GrapheneOS with the hardware attestation API. Direct use of the hardware attestation API provides much higher assurance than using SafetyNet so these apps have nothing to lose by using a more meaningful API and supporting a more secure OS.
- Quote https://grapheneos.org/usage#sandboxed-play-services