this post was submitted on 11 Mar 2026
102 points (99.0% liked)
Privacy
4195 readers
234 users here now
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The issue is that OS's like /e/ and Jolla are quite insecure, meaning a verification that they're "safe" can be a lie if the device is exploited, which it easily can.
GrapheneOS has their own attestation system, and some banks are using it.
GrapheneOS's propaganda about every android ROM being insecure except their's seems to working.
Nothing is 100% safe. There are varying degrees. GrapheneOS can be exploited just "the most secure phone OS" that is supposedly iOS.
If attestation is wrong and GrapheneOS is slamming another group for making an attestation system but GrapheneOS has its own attestation, doesn't that seem a bit hypocritical?
They complain about /e/ and Sailfish because they are genuinely bad. You can see how bad /e/ is in my recent post.
They used to support DivestOS which was an OS designed for phones which don't support Graphene.
Even GrapheneOS is not as insane to suggest ebanking should be restricted to locked down platforms.
EU should ban banks from requiring hardware attestation and other "security" excuses to refuse serving people.
Hardware attestation verifies that the phone and the OS its running on are real and not an emulator or a fake malware laced version.
It ensures that you don't get your bank account stolen by a fake ROM with an infostealer inside.
No, it verifies that the phone is running an approved OS. If the app developer does not add your OS' keys it will fail. This included GrapheneOS.
We have been web banking for decades on platforms without hardware attestation. The potential for anti-competitiveness abuse is not worth it.
It also does not protect the user. If your system is actually compromised they can simply replace the app, not allow it to run etc. I don't see how it protects the user if they chose to run an emulator, what exactly is the threat to the user there?
If someone injects malware into your GrapheneOS image then the attestation won't pass. That is how it works.
Where did I say a malware injected GrapheneOS image will pass hardware attestation?
The problem is that an unmodified GrapheneOS image may also not pass hardware attestation if the app developer has not whitelisted GrapheneOS's key.
Also I hope GrapheneOS would simply inform the user or refuse to boot if the image does not pass attestation. In that case an app itself requiring attestation, based on it's own list of accepted keys, has no security value, only gatekeeping potential.