I want to mainly use it for privacy over its “security”. I don’t know what makes everyone fine with running it on fucking google pixels. Is there some kind of “low security” version or something for other phones? I’m so tired of certain organizations infiltrating privacy communities and making people believe in improving “security” by voluntarily giving up on privacy and using even non free software like that insecurities blog and other people.
You must log in or register to comment.
Security enables privacy, that’s why they are commonly referenced together. From a hardware standpoint, Pixels are the most secure phones on the market and Google makes them with dev’s in mind. This is why Graphene OS, which is based on AOSP, currently only runs on Pixels.
From Graphene’s FAQ
Many other devices are supported by GrapheneOS at a source level, and it can be built for them without modifications to the existing GrapheneOS source tree. Device support repositories for the Android Open Source Project can simply be dropped into the source tree, with at most minor modifications within them to support GrapheneOS. In most cases, substantial work beyond that will be needed to bring the support up to the same standards. For most devices, the hardware and firmware will prevent providing a reasonably secure device, regardless of the work put into device support.
To get down to your actual reservations about privacy: when you flash a new Graphene ROM onto your phone, you’re replacing all the software down to the low level stuff. The AOSP devs, google devs, XDA devs, and graphene devs refer to it at flashing the firmware. The only google code you’re running is the Android bootloader, which goes for any smartphone.
Further, if you look into it, “Google” pixels aren’t actually manufactured by Google. This means their hardware is about as trustworthy as any other phone’s. As to why Graphene only officially supports Pixels, I do not fully understand their needs/reasoning, just that they have determined it is the best for them.
Basically my point boils down to: if you have issues with the hardware, the same should go for any smartphone. If you’re bothered by google software, you needn’t worry insofar as you trust the Graphene devs. If you consider the Pixels “tainted” by association to Google, then the same should go for Graphene and any other ROMs, since the kernel is based off of the AOSP—a google run project—and any android phone, for the same reason.
All that being said, CalyxOS supports a slightly wider variety of devices.
https://grapheneos.org/faq#recommended-devices
Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:
Support for using alternate operating systems including full hardware security functionality
Complete monthly Android Security Bulletin patches without any regular delays longer than a week
At least 5 years of updates from launch for phones (Pixels now have 7) and 7 years for tablets
Vendor code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)
Linux 5.15 or Linux 6.1 Generic Kernel Image (GKI) support
Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
Hardware memory tagging (ARM MTE or equivalent)
BTI/PAC, CET or equivalent
PXN, SMEP or equivalent
PAN, SMAP or equivalent
Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components
Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more timesVerified boot with rollback protection for firmware
Verified boot with rollback protection for the OS (Android Verified Boot)
Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)StrongBox keystore provided by secure element
Hardware key attestation support for the StrongBox keystore
Attest key support for hardware key attestation to provide pinning supportWeaver disk encryption key derivation throttling provided by secure elementInsider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
Inline disk encryption acceleration with wrapped key support
64-bit-only device support code
Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
