Hacker News Reader

Comment by rustcleaner | Hacker News Reader

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.

View on HN

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.

Still, a 'degraded' GrapheneOS as my proposed CarbonOS, beats /e/, Lineage, Calyx, and stock. Not doing CarbonOS is throwing the baby (non-hardware hardening and features) out with the bathwater (the lack of hardware hardening). I for one do not wholly rely on Titan and use a long alphanumeric password on my primary profile to ensure BFU disk encryption isn't violated, while living in secondary daily-driver profiles which are PIN protected for ease of use. If I suspect phone seizure becomes a non-infinitesimal possibility, I can just reboot! Additionally, I would love to see an option in GOS that allows me to change the action bound to the panic sequence (5+ rapid presses of power): I would never call police using that sequence, I would 100x rather that sequence cause a shutdown instead. That way if I am asked to hand over my phone I can just panic sequence it as I am removing it from my pocket. As it stands now I would have to pause to interact with the screen to shut it off, significantly increasing the likelihood of the adversary snatching it before I could get it into BFU.

The majority of our added exploit protections are based on hardware security features and that will only be increasing over time. MTE, PAC, BTI, hardware-based blocking of USB connections/data and far more are hardware features used to implement protections in software. MTE is going to be a growing part of how we build memory corruption defenses in the kernel and userspace. Once 6th/7th gen Pixels are end-of-life and we finally flip the switch on using MTE in all user installed apps by default, we can focus even more on expanding MTE-based protections.

The vast majority of users do not use a strong passphrase. The recommended high security setup is a strong passphrase and 2-factor fingerprint+PIN secondary unlock for convenience. Using a weaker PIN for secondary users for convenience is not our recommended approach.

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.

Reply on news.ycombinator.com