WARNING:
I have NOT done any research in any of the info provided ij this post, only info that I just so happened to sumble upon, so please take this post with a grain of salt
What happened?
With the Motorola Signiture 27, GrapheneOS finally broke free from being Pixel-exclusive. However, a good question meeds to be asked for me: How slim are the chances that next year’s Fairphone could support GrapheneOS?
Why I even considered it as a possibility
I’ve seen some people saying Fairphone will support GrapheneOS, but there’s lots of evidence against it, saying that the bare minimum requirements
Why I think it’s unlikely:
Fairphone has historically lacked in terms of specs. While I don’t have a shoot out of the camera or ANY specs like most people (my bare minimum res quality is 240p lol), as long as the technology used for the hardware stays modern, however I heard GrapheneOS had specific requirements in order to gain support for a device model. Idk what those are other than a relockable bootloader. While this year’s hardware improvements have been much bettet than the past, I don’t think it will be enough even if 5he pace is kept or even improved next year
Comment down what you found or correct what I’ve missed or done wrong in the comments
I’d say very slim.
First, GrapheneOS insist on specific hardware which means Fairphone would have to make very specific changes to the device for GrapeheneOS to be supported. This would make the phone more expensive, which is a huge problem for Fairphone: Building a high-quality repairable smartphone with more ethically sourced minerals at a reasonable price is hard enough already.
Second, the team behind GrapheneOS are not exactly masters of diplomacy. I’ve seen them trash Fairphone on multiple occasions, either for association with /e/OS which they seem to think is the product of Satan himself (just like all other phone operative systems other than iOS, stock Android, and GrapheneOS), or because Fairphone supports devices for too long and that this has bad security implications or whatever. They seem to have some sort of specific beef with Fairphone, and I very much doubt either party would be interested in cooperating as a result.
Email fairphone and ask. They already ship versions with /e/ so the possibility is there.
Fairphones with /e/OS is shipped by Murena, a French company who just cooperates with Fairphone. For GrapheneOS to ship on Fairphones Graphene would have to make a similar arrangement. They won’t, for a number of reasons.
Generally GrapheneOS is looking for sufficiently secure hardware it seems.
Non-exhaustive list of requirements for future devices, which are standards met or exceeded by devices starting from Pixel 8 (shiba) through Pixel 10a (stallion):
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 for device support code (firmware, drivers and HALs) At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets Device support 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 6.1, 6.6 or 6.12 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) Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn't used or can't be deployed (BTI/PAC, CET IBT or equivalent) PXN, SMEP or equivalent PAN, SMAP or equivalent Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode and 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 times Verified 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 support Weaver disk encryption key derivation throttling provided by secure element Insider 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 Support for disabling USB data and also USB as a whole at a hardware level in the USB controller Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that's completed Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked
