Graphene OS Vs Calyx OS
Fact Based Review ➤ Are They Really Similar
Should You Use Graphene OS or Calyx OS
Graphene OS and Calyx OS are often compared as similar options for people looking for a DeGoogled OS for their Pixel phones and tablets. Below are some of our fact-based reasons why we recommend Graphene OS over Calyx OS, or in fact any of the other DeGoogled OS alternatives. Keep reading and decide for yourself — David
We also DeGoogle Pixel Phones with Graphene OS and express post Australia Wide and to NZ UK EU CA.
Update Frequency
Calyx OS has a track record of being slower to apply security and feature updates to its OS and core applications than other custom Android operating systems. Prompt security updates are a significant factor to consider when determining if an OS is secure enough for regular use, which is a requirement for privacy. In contrast, Graphene OS manages to stay close to upstream and in some cases even delivers updates before the stock Android OS does. As an example, Graphene OS released the new version of Android [think: significant security / privacy improvements] months ahead of Calyx OS.
Sandboxed Google Play Vs Privileged microG
When Google Play Services are used on Graphene OS, they are confined using the highly restrictive, default untrusted_app SELinux domain. As a result, you have full control as to what these apps can access via permissions, just like any other app you install. Additionally, you can selectively choose which user profiles to install the Sandboxed Google Play in.
MicroG is a partially open-source re-implementation of Google Play Services. On Calyx OS, it runs in the highly privileged domain system_app SELinux like regular Google Play Services, and it uses signature spoofing to masquerade as Google Play Services. This is less secure than Graphene’s Sandboxed Google Play's approach, which does not need access to sensitive system APIs.
When using Sandboxed Google Play, you have the option to reroute location requests to the Play Services API back to the OS location API, which uses satellite based location services. With microG, you have the option to choose between different backend location providers, including shifting trust to another location backend, like Mozilla; using DejaVu, a location backend that locally collects and saves RF-based location data to an offline database which can be used when GPS is not available; or to simply not use a network location backend at all.
Network location providers like Play Services or Mozilla rely the on the MAC addresses of surrounding WiFi access points and Bluetooth devices being submitted for location approximation. Choosing a network location like Mozilla to use with microG provides little to no privacy benefit over Google because you are still submitting the same data and trusting them to not profile you.
Local RF location backends like DejaVu require that the phone has a working GPS first for the local RF data collected to be useful. This makes them less effective as location providers, as the job of a location provider is to assist location approximation when satellite based services are not working.
If your threat model requires protecting your location or the MAC addresses of nearby devices, rerouting location requests to the OS location API is probably the best option. The benefit brought by microG's custom location backend is minimal at best when compared to Sandboxed Google Play.
In terms of application compatibility, Sandboxed Google Play on Graphene OS is always going to be more compatible as it is the same code as what is released by Google. MicroG is a re-implementation of these services. As a result, it only supports the various parts that have been re-implemented, meaning some things such as Google Play Games and In-app Billing API are not yet supported.
Larger apps, especially games, require Play Asset Delivery to be installed, which is currently not implemented in microG. Authentication using FIDO with online services on Android also relies on Play Services, and does not currently work with microG.
Privileged eSIM Activation
Currently, eSIM activation is tied to a privileged proprietary application by Google. The app has the read_privileged_phone_state permission, giving Google access to your hardware identifiers such as the IMEI. On GrapheneOS, the app comes disabled and you can optionally enable it after installing Sandboxed Google Play. On Calyx OS, the app comes installed by default [regardless of whether you choose to have microG or not] and you cannot opt-out. This means that Google still has access to your hardware identifiers regardless of whether or not you need eSIM activation and they can be accessed persistently. For me, this is a line I am not willing to cross!
Privileged App Extensions
Since Android 12, we have support for seamless app updates with third-party app stores. The popular Free and Open-Source Software [FOSS] repository F-Droid doesn't implement this feature and requires a privileged extension to be included with the Android distribution in order to have unattended app updates. Calyx OS includes the privileged extension, which may lower device security. On the other hand, Graphene OS officially recommends Sandboxed Google Play instead. Many FOSS Android apps are also in Google's Play Store, which we access via the anonymous login with the Aurora Store.
Profiles
Graphene OS significantly improves user profiles in multiple ways, such as increasing the limit of how many profiles you can create (32 instead of the standard 4), allowing you to log out of user profiles, disabling app installation, and notification forwarding. All of these improvements make it so user profiles can be daily driven without sacrificing too much usability.
Calyx OS doesn't feature any improvements to user profiles over AOSP, and instead includes a device controller app so that the work profile can be used without needing to download a third party app such as Shelter. However, work profiles are not nearly as flexible [as you're limited to only one] and don't provide the same amount of isolation and security.
Additional Hardening
Graphene OS improves upon AOSP [Standard Android] security with:
Hardened WebView: Vanadium WebView requires 64-bit processes on the WebView process and disables legacy 32-bit processes. It uses hardened compiler options such as -fwrapv and -fstack-protector-strong, which can help protect against stack buffer overflows. APIs such as the battery status API are disabled for privacy reasons. All system apps on GrapheneOS use the Vanadium WebView which means that apps which use WebView will also benefit from Vanadium's hardening. The Vanadium patch set is a lot more comprehensive than CalyxOS's Chromium patch set which is derived from it.
Hardened Kernel: Graphene OS kernel includes some hardening from the linux-hardened project and the Kernel Self Protection Project (KSPP). CalyxOS uses the same kernel as regular Android with some minor modifications.
Hardened Memory Allocator: Graphene OS uses the hardened malloc subproject as its memory allocator. This focuses on hardening against memory heap corruption. Calyx OS uses the default AOSP Scudo Malloc, which is generally less effective. Hardened Malloc has uncovered vulnerabilities in AOSP which have been fixed by Graphene OS such as CVE-2021-0703.
Secure Exec Spawning: Graphene OS spawns fresh processes as opposed to using the Zygote model used by AOSP and Calyx OS. The Zygote model weakens Address Space Layout Randomization (ASLR) and is considered less secure. Creating fresh processes is safer but will have some performance penalty when launching a new application. These penalties are not really noticeable unless you have an old device with slow storage such as the Pixel 3a/3a XL as it has eMMC.
Please note that these are just a few examples and are not an extensive list of Graphene OS's privacy and security hardening. For a more complete list, please read our Understanding Graphene OS page.