zlacker

[return to "Graphene OS: a security-enhanced Android build"]
1. SchwKa+Tn[view] [source] 2025-07-25 00:46:39
>>madars+(OP)
My only problem with Graphene is the ridiculous low number of supported devices, i know I know, security reasons and so on. But I would accept an lower security hardened version but at least have Graphene instead of Google's junk
◧◩
2. crossr+0G[view] [source] 2025-07-25 03:28:31
>>SchwKa+Tn
I actually like Graphene's focus in Pixel. It is available in a lot of countries unlike Fairphone - via Pixel of course.

So Graphene is actually not limited to the developed/western world. As for not supporting other devices, I believe the reason could be the team size and the fact that the fragmented Android world is known for unique shenanigans of every OEM. Besides Google's update/upgrade cycle is another reason it is an appropriate choice.

◧◩◪
3. beefle+kP[view] [source] 2025-07-25 05:32:47
>>crossr+0G
por que no los dos?
◧◩◪◨
4. gf000+u01[view] [source] 2025-07-25 07:30:16
>>beefle+kP
Because as mentioned, Fairphone has lackluster hardware security.

You can have the best alarm system in the word, if you leave the back door open and anyone can just walk in from the street.

◧◩◪◨⬒
5. beefle+DK2[view] [source] 2025-07-25 19:23:24
>>gf000+u01
Okay, but the danger of vendor lockout is very great because gOS only supports one brand of phone. The justification for limiting support to pixels is that it has trusted computing features, but these are made unnecessary by having a long password.

You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones

◧◩◪◨⬒⬓
6. gf000+fb3[view] [source] 2025-07-25 21:50:50
>>beefle+DK2
> but these are made unnecessary by having a long password.

Yeah, that's completely how security works...

◧◩◪◨⬒⬓⬔
7. beefle+6c5[view] [source] 2025-07-26 20:19:02
>>gf000+fb3
It is. The idea behind using a embedded trusted computing device in this fashion is that you can store a AFU encryption/decryption keys in the trusted computing device and lower-entropy password like a 4-digit pin or biometrics, with the trusted computing device preventing a brute force attack.

But this is unnecessary if your encryption password has enough entropy in the first place, because it cannot be brute forced. This is the security model of most linux distros that use full disk encryption with LUKS. And android already lets you do this, it is just less convenient.

I use grapheneOS with a high entropy BFU password and a low entropy biometric AFU fingerprint. My linux setup works in the same way. The BFU password is the only "real" password that secures you and encrypts your data. The AFU password is a just temporary screen lock that is vulnerable to side channel attacks because the decryption keys are still in memory.

[go to top]