Hacker News Reader

Comment by subscribed | Hacker News Reader

Fairphone is dangerously insecure. Nothing phone is not much better.

It's not only the design of the hardware, but also patches for vulnerabilities and delivering updates for several years.

You're suggesting it's ideological (which is completely untrue), while the fact is: pixels are at the very moment the only Android hardware secure enough to even care about hardening: https://grapheneos.org/faq#future-devices

(there's little sense in securing the OS if the hardware doesn't allow disconnecting the USB or there is no secure element throttling PIN attempts, right?)

View on HN

Source on Fairphone being insecure? I'm moving to Android app development and considered it for repairability/mission factors.

From what I found they're brilliant on repairability, but not so much on security, which is a bummer :(

Couple of pieces on hardware:

- Fairphone does not include a secure element making brute-forcing PIN trivial

- Fairphone 4 used TEST KEYS for verified boot: https://forum.fairphone.com/t/bootloader-avb-keys-used-in-ro... The above alone shows insecurity by design.

I cannot find any of Fairphone technical documentation that would provide details on their implementation of the TEE/HSM. As of now I believe it's only Pixel's Titan and Samsung's KNOX that provide a discrete secure element on Android devices.

Android project recommends secure element to process sensitive data: https://source.android.com/docs/security/best-practices/hard... What it's supposed to provide: https://developer.android.com/privacy-and-security/keystore

On vendor: Drivers, firmware patches, OS upgrades are a necessity, not an option: most security and privacy updates are not backported. Vendor can't just wait for AOSP to deliver all the patches. Vendor must show a track record providing updates to their hardware

- After a lengthy two-year delay, the phone got a taste of Android 12 in February 2023, with Android 13 arriving relatively quickly in October 2023. For Android 14, Fairphone promised to roll out the update in H2, 2024, almost a year after Google released it. Now, with less than two months left in the year, the company is postponing the update's release to 2025. -- https://www.androidpolice.com/fairphone-4-long-delayed-andro...

- their Security Bulletin patches are consistently 1-2 months behind

- Fairphone 5 is still on Android 14 (since Jul 2024). Android 15 has been released in September 2024. Year and a half later AOSP is on Android 16.

- Fairphone 6 is still on Android 15

- Fairphone 5 and 6 latest security patches are from June 2025: https://support.fairphone.com/hc/en-us/articles/244637136412...

For comparison GrapheneOS had eight releases in July alone (GrapheneOS had a full A16 release on 30th of June for all supported devices). Security patches are usually released within one-three days (or earlier, from the tree, without waiting for being published in the bundle)

GOS Release for Pixel 9 was ready three days after the device launch.

Exploitability matrix as per Cellebrite: https://discuss.privacyguides.net/t/updated-cellebrite-iphon... That supports the claim the hardware + OS holds.

Just adding minor context:

> - Fairphone 5 is still on Android 14 (since Jul 2024).

The Android 15 update was actually released this week! https://support.fairphone.com/hc/en-us/articles/186828004651...

> - Fairphone 6 is still on Android 15

Android 16 was released less than half a month before the release of the FP6, which itself is less than a month ago. Seems reasonable that it wouldn't ship the latest version under those circumstances.

After a lengthy two-year delay, the phone got a taste of Android 12 in February 2023, with Android 13 arriving relatively quickly in October 2023. For Android 14, Fairphone promised to roll out the update in H2, 2024, almost a year after Google released it.

It is also worth mentioning that Android Security Bulletins generally only contain backports of patches for High and Critical vulnerabilities. Most non-Pixel/GrapheneOS phones only get all the other fixes when moving to the next major release [1]. So getting the next major Android release is important (getting to a recent patch-level alone is not enough).

I can completely understand that Graphene does not want to support Fairphone and others, their security/privacy goals are the complete opposite of what those phones provide.

[1] https://discuss.grapheneos.org/d/23462-grapheneos-version-20...

> - Fairphone does not include a secure element making brute-forcing PIN trivial

i am trying to under this but i do not get it. it is an encrypted phone with no external to the attacker access. how can you brute it??

https://github.com/urbanadventurer/Android-PIN-Bruteforce

Fairphones don't switch USB ports automatically into "charging only" like GrapheneOS does.

what are you talking about? are you talking about the kernel or the vendor?

if so they ought to be replaced anyways for a secure phone. please tell me graphene is not rawdogging Alphabet's compiled stuff.

if you are talking about firmware blobs then ok but still weird as the blobs are the same per soc

E: if you are talking about tpm and other stuff, eh. they are closed source anyways and i, as a user, cannot actually validate them

> what are you talking about? are you talking about the kernel or the vendor?

Yes. See my response to the sibling comment (I don't want to pollute the discussion with sending twice the same)

> please tell me graphene is not rawdogging Alphabet's compiled stuff

What do you mean? Patching and compiling AOSP tree like every OEM does is "rawdogging Alphabet's compiled stuff" now? Or allowing users to run unprivileged/sandboxed Google services in the isolated user profile they choose?

> if so they ought to be replaced anyways for a secure phone. please tell me graphene is not rawdogging Alphabet's compiled stuff.

Say you don't know what GOS does without saying that out loud.

> if you are talking about tpm and other stuff, eh. they are closed source anyways and i, as a user, cannot actually validate them

Yeah, closed source BUT they exist so for example there's actual, physical throttling of the PIN, Weaver token is stored in the safe place, and we can have downgrading protection support, etc

then i d rather use lineageOS that does change vendor, kernel and system lol

Reply on news.ycombinator.com