mirror of
https://github.com/privacyguides/privacyguides.org.git
synced 2025-05-02 06:16:27 -04:00
Remove CalyxOS (#1518)
Co-Authored-By: matchboxbananasynergy <107055883+matchboxbananasynergy@users.noreply.github.com> Signed-off-by: Daniel Gray <dng@disroot.org>
This commit is contained in:
parent
65874da53c
commit
2176a3a2de
5 changed files with 18 additions and 53 deletions
|
@ -1,12 +1,15 @@
|
|||
---
|
||||
title: "GrapheneOS vs CalyxOS"
|
||||
title: "Why we recommend GrapheneOS over CalyxOS?"
|
||||
icon: 'material/cellphone-cog'
|
||||
---
|
||||
|
||||
GrapheneOS and CalyxOS are commonly compared as similar options for people looking for an alternative Android OS for their Pixel devices. Below are some of the reasons we recommend GrapheneOS over CalyxOS.
|
||||
|
||||
## Profiles
|
||||
|
||||
CalyxOS includes a device controller app so there is no need to install a third-party app like Shelter.
|
||||
|
||||
GrapheneOS extends the user profile feature, allowing you to end a current session. To do this, select *End Session* which will clear the encryption key from memory. There are plans to add a [cross profile notifications system](https://github.com/GrapheneOS/os-issue-tracker/issues/88) in the future. GrapheneOS plans to introduce nested profile support with better isolation in the future.
|
||||
GrapheneOS extends the user profile feature, allowing you to end a current session. To do this, select *End Session* which will clear the encryption key from memory. GrapheneOS also provides [cross-profile notification forwarding](https://grapheneos.org/features#notification-forwarding). GrapheneOS plans to introduce nested profile support with better isolation in the future.
|
||||
|
||||
## Sandboxed Google Play vs Privileged microG
|
||||
|
||||
|
@ -22,9 +25,11 @@ Local RF location backends like DejaVu require that the phone has a working GPS
|
|||
|
||||
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 Play Services.
|
||||
|
||||
In terms of application compatibility, Sandboxed Google Play on GrapheneOS outperforms microG on CalyxOS due to its support for many services which microG has not yet implemented, like [Google Play Games](https://play.google.com/googleplaygames) and [In-app Billing API](https://android-doc.github.io/google/play/billing/api.html). Larger apps, especially games, require Play Delivery to be installed, which is currently not implemented in microG. Authentication using [FIDO](../basics/multi-factor-authentication.md#fido-fast-identity-online) with online services on Android also relies on Play Services, and does not currently work with microG.
|
||||
In terms of application compatibility, Sandboxed Google Play on GrapheneOS is always going to be more compatible as it is the same code as what is released by Google. microG is a reimplementation of these services. As a result of that it only supports the various parts that have been reimplemented, meaning some things such as [Google Play Games](https://play.google.com/googleplaygames) and [In-app Billing API](https://android-doc.github.io/google/play/billing/api.html) are not yet supported.
|
||||
|
||||
[^1]: It should be noted that microG still uses proprietary Google binaries for some of its components such as DroidGuard. Push notifications, if enabled, still go through Google's servers just like with Play Services. Outside of default microG setups like on CalyxOS, it is possible to run microG in the unprivileged `untrusted app` SELinux domain and without the signature spoofing patch. However, microG's functionality and compatibility, which is already not nearly as broad as Sandboxed Play Services, will greatly diminish.
|
||||
Larger apps, especially games, require Play Delivery to be installed, which is currently not implemented in microG. Authentication using [FIDO](../basics/multi-factor-authentication.md#fido-fast-identity-online) with online services on Android also relies on Play Services, and does not currently work with microG.
|
||||
|
||||
[^1]: It should be noted that microG still uses proprietary Google binaries for some of its components such as DroidGuard. Push notifications, if enabled, still go through Google's servers just like with Play Services. Outside of default microG setups like on CalyxOS, it is possible to run microG in the unprivileged [`untrusted app`](https://source.android.com/security/selinux/concepts) SELinux domain and without the signature spoofing patch. However, microG's functionality and compatibility, which is already not nearly as broad as Sandboxed Play Services, will greatly diminish.
|
||||
|
||||
## Privileged eSIM Activation Application
|
||||
|
||||
|
@ -32,7 +37,7 @@ Currently, eSIM activation is tied to a privileged proprietary application by Go
|
|||
|
||||
On GrapheneOS, the app comes disabled and can be *optionally* enabled by the user after they have installed Sandboxed Play Services.
|
||||
|
||||
On CalyxOS, the app comes installed by default (regardless of whether you choose to have microG or not) and cannot be opted out. This is particularly problematic, as it means Google still has access to the user's hardware identifiers regardless of whether they even need the eSIM activation or not, and can access them persistently.
|
||||
On CalyxOS, the app comes installed by default (regardless of whether you choose to have microG or not) and cannot be opted out. This means Google still has access to your hardware identifiers regardless of whether or not you need eSIM activation and can be accessed persistently.
|
||||
|
||||
## Privileged App Extensions
|
||||
|
||||
|
|
|
@ -34,6 +34,8 @@ Verified Boot ensures the integrity of the operating system files, thereby preve
|
|||
|
||||
Unfortunately, OEMs are only obliged to support Verified Boot on their stock Android distribution. Only a few OEMs such as Google support custom AVB key enrollment on their devices. Additionally, some AOSP derivatives such as LineageOS or /e/ OS do not support Verified Boot even on hardware with Verified Boot support for third-party operating systems. We recommend that you check for support **before** purchasing a new device. AOSP derivatives which do not support Verified Boot are **not** recommended.
|
||||
|
||||
Many OEMs also have broken implementation of Verified Boot that you have to be aware of beyond their marketing. For example, the Fairphone 3 and 4 are not secure by default, as the [stock bootloader trusts the public AVB signing key](https://forum.fairphone.com/t/bootloader-avb-keys-used-in-roms-for-fairphone-3-4/83448/11). This breaks verified boot on a stock Fairphone device, as the system will boot alternative Android operating systems such (such as /e/) [without any warning](https://source.android.com/security/verifiedboot/boot-flow#locked-devices-with-custom-root-of-trust) about custom operating system usage.
|
||||
|
||||
## Firmware Updates
|
||||
|
||||
Firmware updates are critical for maintaining security and without them your device cannot be secure. OEMs have support agreements with their partners to provide the closed-source components for a limited support period. These are detailed in the monthly [Android Security Bulletins](https://source.android.com/security/bulletin).
|
||||
|
@ -42,6 +44,8 @@ As the components of the phone, such as the processor and radio technologies rel
|
|||
|
||||
EOL devices which are no longer supported by the SoC manufacturer cannot receive firmware updates from OEM vendors or after market Android distributors. This means that security issues with those devices will remain unfixed.
|
||||
|
||||
Fairphone, for example, markets their devices as receiving 6 years of support. However, the SoC (Qualcomm Snapdragon 750G on the Fairphone 4) has a considerably shorter EOL date. This means that firmware security updates from Qualcomm for the Fairphone 4 will end in September 2023, regardless of whether Fairphone continues to release software security updates.
|
||||
|
||||
## Android Versions
|
||||
|
||||
It's important to not use an [end-of-life](https://endoflife.date/android) version of Android. Newer versions of Android not only receive security updates for the operating system but also important privacy enhancing updates too. For example, [prior to Android 10](https://developer.android.com/about/versions/10/privacy/changes), any apps with the [`READ_PHONE_STATE`](https://developer.android.com/reference/android/Manifest.permission#READ_PHONE_STATE) permission could access sensitive and unique serial numbers of your phone such as [IMEI](https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity), [MEID](https://en.wikipedia.org/wiki/Mobile_equipment_identifier), your SIM card's [IMSI](https://en.wikipedia.org/wiki/International_mobile_subscriber_identity), whereas now they must be system apps to do so. System apps are only provided by the OEM or Android distribution.
|
||||
|
@ -52,6 +56,9 @@ It's important to not use an [end-of-life](https://endoflife.date/android) versi
|
|||
|
||||
Should you want to run an app that you're unsure about, consider using a user or work profile.
|
||||
|
||||
## Media Access
|
||||
Quite a few applications allows you to "share" a file with them for media upload. If you want to, for example, tweet a picture to Twitter, do not grant Twitter access to your "media and photos", because it will have access to all of your pictures then. Instead, go to your file manager (documentsUI), hold onto the picture, then share it with Twitter.
|
||||
|
||||
## User Profiles
|
||||
|
||||
Multiple user profiles can be found in **Settings** → **System** → **Multiple users** and are the simplest way to isolate in Android.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue