Comment by evolve2k
2 days ago
Anyone have any updates on why this device can’t support or get behind Graphene OS? A repairable and secure phone is my desired option for a phone that’s truely mine and I’m sure this is true for many others also.
From my understanding it’s not there as the Graphene team says that fairphone haven’t taken security hardware seriously and there’s key hardware security features missing that means they are not even interested to look at supporting the device.
Keen for latest updates on this, happy to be corrected.
Someone from GrapheneOS was very active in this thread: [0], here is a response the GrapheneOS person links to themselves: [1]
[0] https://news.ycombinator.com/item?id=49355122
[flagged]
While yes I am on GrapheneOS' side on these issues, I'm surprised nobody clones the GrapheneOS repo and simply disables the minimal handful of features which block it from working on devices. Maybe calling the clone CarbonOS? If MTE is required to boot GrapheneOS and Fairphones don't have MTE, then Fairphone clones GrapheneOS and disables MTE for its images. Graphene has so many features beyond just hardware security that other Androids lack, that it would be worthwhile to do this and it would still be higher security than the others (even if it's below GrapheneOS' own full security). Sensor & network permissions, storage & contact scopes, autoreboot, scrambled pin, radio auto-off, MAC address randomization, and more, I'm sure don't require MTE or Titan etc. Just follow GrapheneOS as upstream, making sure that the minimal set of changes needed to get it working on other/older devices transfers with the new updates.
Fairphones are missing many of the required features and don't provide reasonable updates. An incomplete port of GrapheneOS won't provide decent security for users. It won't have decent encryption for the vast majority of users not using a strong passphrase and it won't defend well against exploits. It will end up with an end-of-life kernel and drivers/firmware lagging far behind on updates.
MTE is required for the majority of the additional protection provided by GrapheneOS against memory corruption exploits. Nearly all remote exploits and most local exploits involve memory corruption. MTE is only going to become more important as we implement deeper integration for it.
I think it would just be a lot of work. And if you went down that road, you would be against other teams with bigger marketing and a bigger community.
As in: people who do care enough to understand the technical arguments tend to go for GrapheneOS when they can. But if you build a "degraded GrapheneOS", you are not targetting those. For someone who doesn't care about what GrapheneOS brings, why would they use your system versus /e/OS?
DivestOS was a thing at some point, which was technically very interesting. But there wasn't much of a differentiator since the people who already cared about what DivestOS was doing were probably already looking at getting GrapheneOS.
Lack of MTE is not the only huge reason why the GrapheneOS team refuses most devices. Most vendors' lack of timely bugfixes for device-specific drivers and firmware, and no commitment to keep providing bugfixes for a number of years is another major factor.
2 replies →
[flagged]
1 reply →
MTE is not the only blocker here. Pixel 7 series do not have it and are currently supported by GrapheneOS. There are other concerns regarding things like a proper secure element implementation and timely firmware/binary blob updates.
GrapheneOS requires MTE for any newly added devices. Pixel 6 and Pixel 7 series devices do not meet the current requirements. Pixel 8 and later are the devices meeting the full requirements.
Devices are supported until end-of-life rather than being dropped when they no longer meet the requirements. Pixel 6 is nearly end-of-life and Pixel 7 will be end-of-life in a bit over a year. Both have 5 years of updates from launch as opposed to 7 years for the Pixel 8 and later.
We want to require 7 years of updates for new devices rather than 5 but have left it at 5 to help budget devices meet our requirements.
Right, but still my CarbonOS idea ('degraded' GrapheneOS) is better than /e/, Lineage, Calyx, and stock. By 'degraded' I mean the minimal changes to current GrapheneOS needed to get it working on a given GrapheneOS-unsupported device.
2 replies →
That's highly inaccurate information. MTE is included on a large number of smartphones beyond Pixels. It's heavily integrated into iOS on the iPhone 17 as their Memory Integration Enforcement feature. MTE enables massive security improvements against exploits and Pixels have had it since the Pixel 8 in October 2023.
Traditional desktop computers have atrocious privacy and security throughout hardware, firmware and software. That isn't a relevant comparison for GrapheneOS. Recent Mac hardware does support MTE and so will non-Mac devices using Snapdragon chips. Qualcomm has added MTE support for their latest flagship mobile SoC platform and will bring it elsewhere. MediaTek and Exynos have also added MTE support.
MTE does not have the substantial performance or battery life impact you're portraying it as having. It's also far more useful than you're portraying it as being. Apple would not have extensively integrated MTE if they had to give up significant performance or battery life. iPhones have a lot of focus on security but aren't willing to make significant sacrifices in those areas for it, at least for the default settings. Their Memory Integrity Enforcement entirely based on MTE is always enabled in the kernel and the large portion of userspace where they deployed it. It's not only used for Lockdown Mode.