Suggestion for a Potential Collaboration Between Fairphone and GrapheneOS

My main concern is to avoid generating profits for Google. I don’t need it to be perfect.

1 Like

Then use an adblocker whenever it is possible

advertising is Google main business

Enable Private DNS and set it to Adguard DNS, Mullvad DNS, AhaDNS or Blah DNS.

Google ads are now blocked from loading on your entire phone which should logically generate 0 cashmoneys for Google.

Edit: Apparently I can’t spell today

Privacy friendly, fair and secure devices are the backbone of digital freedom. Please strengthen the backbone of millions of people by supporting Graphene on the next Fairphone.
All other alternatives to Graphene are compromises:

Thanks.

1 Like

Please ask the maker of Graphene OS, it’s in their hands.

1 Like

They seem pretty clear about it. Fairphone does not apply for the standards set by GrapheneOS. The post is from a few years ago, but I suppose the criticism still stands.

https://www.reddit.com/r/GrapheneOS/comments/10b5x4n/has_anyone_managed_to_install_grapheneos_on_a/j67pbny

1 Like

It will literally never happen.

The closest we’re going to get is CalyxOS and we already have support for that.

1 Like

Graphene is a security-oriented OS. It is using some hardware which is for the moment only provided by pixel phones. Providing this hardware is fairphone’s part. As buying a google phone is a no-go, please provide this hardware. Fairphone would be the only google free and secure phone in the world.

1 Like

Why not? It is technically possible. If it is demanded, it will happen.

Fairphone would need to meet this long list of requirements. It won’t happen form a small company like this.

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 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 / 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
3 Likes

It would require Fairphone to make so many changes that it’s in practice unachievable. They would have to stay up to date on security updates for starters, and we all know if it’s going with that.

2 Likes

Please check with Graphene which of these requirements are necessary, maybe the list becomes smaller. If Fairphone could position itself as fair and security oriented phone, I bet the demand would increase a lot, especially in these days.

It is not negotiable otherwise other bigger manufacturers phone would have been supported too and this is not even the full list.

2 Likes

They have already said that they aren’t interested in a “GrapheneOS Lite” that takes away a bunch of security features to allow broader usage.

4 Likes

That means buying a Fairphone (or any other Lineage OS supported phone) and compromise on security, or support google. And no alternatives to that?

Yes, or you use stock + advanced protection or something like that on a mainstream phone. (Sony, Samsung)

buying a second-hand Pixel

2 Likes