Andromxda 🇺🇦🇵🇸🇹🇼

That rate limiting can easily be bypassed by an attacker. In order to be effective, the rate limit needs to be enforced by tamper-resistant hardware, i.e. a secure element. Here are some of the requirements for a secure element: https://developer.android.com/privacy-and-security/keystore#StrongBoxKeyMint

An implementation of StrongBox KeyMint must contain the following:

Its own CPU
Secure storage
A true random-number generator
Additional mechanisms to resist package tampering and unauthorized sideloading of apps
A secure timer
A reboot notification pin (or equivalent), like general-purpose input/output (GPIO)

For details, I recommend reading:

• https://grapheneos.org/faq#encryption
• https://blog.quarkslab.com/android-data-encryption-in-depth.html

Only devices with a proper implementation of a secure element (Titan M2, i.e. Pixel 6 or later, or the Apple SEP, i.e. iPhone 12 or later) are actually resistant to brute-force attacks by forensic data extraction tools, such as Cellebrite or GrayKey. GrapheneOS has obtained some internal documents from multiple forensics companies. They published the Cellebrite docs at https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation

Specifically, I recommend looking at this chart:

It clearly shows that data cannot be extracted from iPhones with the SEP, unless the device is in the AFU state, meaning that the encryption keys are kept in memory.

Those are the charts for Pixels:

Certainly not

Sandboxed Google Play is one of the key features of GrapheneOS. So far no other OS has allowed users to enjoy the full functionality of Android Auto, the Pixel LPA for managing eSIMs, and the Google Mobile Services suite (not talking about the other Pixel OS stuff) with the only exception being GPay, without full sandboxing, and without granting excessive privileges (SGP is unprivileged, the eUICC LPA obviously requires higher privileges for managing eSIMs, but it’s fully sandboxed and can’t communicate with Play services, or access the internet)

GrapheneOS has criticized Fairphone from a security perspective for a long time, long before any partnerships with OEMs were ever made. GrapheneOS chose to partner with this specific company (which they don’t want to broadly disclose yet) because they have shown, that they actually care about security, and are willing to invest time and effort to meet the GrapheneOS device requirements, not the other way around.

the team refuses to use reverse-engineered hardware interfaces

Small correction: Current and future GrapheneOS releases for Pixels are produced by reverse-engineering Pixel OS releases. adevtool was developed together with the developer of ProtonAOSP back then, to automate extracing several components from the stock Pixel OS.

Fairphone is very far from meeting GrapheneOS’ requirements: https://grapheneos.org/faq#future-devices

They also openly supported harassment of GrapheneOS developers in the past.

A lot of their marketing is very misleading, or completely false. They’re not the moral and ethical company they claim to be.

Snapdragons finally somewhat caught up to Google’s Tensors and the Titan M with the Qualcomm SPU and by implementing the ARM MTE

What makes you think so? This (admittedly pretty vague) response indicates quite the opposite: https://grapheneos.social/@GrapheneOS/115118480213473033

It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.

It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.

Pixels will be supported until EoL. You can get a used Pixel 8a or 9a, which will get supported until May 2031 and April 2032 respectively. Both feature modern, important hardware security features, such as the ARM memory tagging extension.

This is incorrect. The sideloading checks are implemented in Play Protect, which needs elevated privileges to function. On GrapheneOS, Google Play services run with normal privileges, just like any other user-installed app. This means, there are no Play Protect checks in GrapheneOS, and there will never be. It would only be possible on ROMs, such as LineageOS with Gapps, where Play services are installed as system apps, running with higher privileges than all other apps.

Nothing needs to be disabled, since it isn’t present in GrapheneOS in the first place. The sideloading checks are implemented in Play Protect, which needs elevated privileges to function. On GrapheneOS, Google Play services run with normal privileges, just like any other user-installed app.

There are several supported apps, such as Curve Pay, PayPal, and banking apps that have their own tap-to-pay implementation.

https://shkspr.mobi/blog/2025/06/contactless-payments-with-grapheneos/

https://grapheneos.social/@GrapheneOS/115295538501760765

You can also use the contactless payments supported tag when searching the GrapheneOS banking app compatibility list on GitHub. https://github.com/PrivSec-dev/banking-apps-compat-report/issues?q=is%3Aissue+label%3A"contactless+payments+supported"