Hacker News Reader

Comment by protimewaster | Hacker News Reader

I thought one of the issues for Fairphone is that their security update schedule / security practices are a bit lax? Their phones are regularly requested by users to be targeted by GrapheneOS, but GOS developers contend that the security practices for the Fairphone are problematic. They apparently get security updates late and don't properly implement verified boot and attestation.

I like the devices, but I've stuck with Pixel devices for the better security practices. Honestly, I'm a little surprised that a university wouldn't be concerned about late security updates and the like.

View on HN

I was going to keep to myself on this one, but this is a good jump-in point.

The security capabilities of their hardware are what makes GrapheneOS incompatible to target the phone, Not any specific security practices of the developers of Fairphone.

Having said that: if there’s a way to MDM GrapheneOS, I’d be looking at that also!

The n+ patch interval on Lineage, /e/ and the rest of them, that’s plain and simply more days your administrators are at risk of giving up the keys to your castle - and that’s a tough pill to swallow!

>They apparently get security updates late and don't properly implement verified boot and attestation.

It doesn't matter if their os gets security updates late, becase security updates depend on the rom maker this case grapheneos.

That's not entirely correct. There are also updates to the baseband, bootloader, binary driver blobs, etc. E.g., the bootloader for the FP3 was set to trust roms signed with the AOSP test keys (https://forum.fairphone.com/t/bootloader-avb-keys-used-in-ro...). That's not something fixable by the OS / rom maker.

The security issues stemming from such things are likely real, as well. There was a paper released some time back, about binary blobs, that found:

> Our results reveal that device manufacturers often neglect vendor blob updates. About 82% of firmware releases contain outdated GPU blobs (up to 1,281 days). A significant number of blobs also rely on obsolete LLVM core libraries released more than 15 years ago. To analyze their security implications, we develop a performant fuzzer that requires no physical access to mobile devices. We discover 289 security and behavioral bugs within the blobs. We also present a case study demonstrating how these vulnerabilities can be exploited via WebGL.

(From https://arxiv.org/html/2410.11075)

These risks don't seem to materialize if you're not targeted by something like an intelligence agency. Not sure publicly funded research has such security requirements, at least by default (they can always buy custom equipment for a project, or just not put such data on devices you take home / out and about). Might be worth it compared to the very real benefits it has around the world by paying good salaries and fairer material sourcing

That's probably true, but some of the mistakes FP has made in the past could probably be widely exploited, so it doesn't instill a lot of confidence IMO. E.g., they were signing their OS images with the AOSP test keys.

It's not a particularly old company (a little over ten years I think?), so presumably they've had to learn a lot of those kinds of lessons at the start of their lifetime. But at this stage, I'd assume they've learned the lowest-hanging lessons, at least.

Reply on news.ycombinator.com