The problem with this is that so many apps use Google Play Services. If I didn’t want a phone that used Google, I wouldn’t use an OS that bent backwards to make it work.

GrapheneOS doesn’t “bend backwards” to make apps relying on Play Services work. Sandboxed Google Play is highly compatible and all you need to do is install the apps, just like you would any other apps. The argument that since many apps require Google Play Services, you should use stock OS where they have privileged access rather than being sandboxed doesn’t make a lot of sense.

The sandbox model is OK in theory, except when your bank app asks for permissions for microphone, camera, contacts and files, and refuses to start without them.

The app model is a bit broken IMO and GrapheneOS both enables and perpetuates it.

Apps installed on operating systems that don’t have a sandbox and thus a permission model get access to straight up everything. Your scenario is exactly why GrapheneOS features contact and storage scopes; as an alternative to the regular permissions for more granular control. You can grant an app only a subset of contacts/files or nothing at all, the app won’t complain since on its end, everything’s been supposedly granted. There are more planned features to address other permissions in a similar way. Furthermore you could put it in its own little box via a secondary profile (you can have up to 32), and have that only run when you need it.

I might be being a bit naïve here, but Android 14 came out in October, 4 months prior to LOS 21, which is not particularly long. Android 13 is still supported by upstream. This sounds a bit like running RHEL or Debian vs bleeding edge Arch, no? It’s a common debate whether RHEL systems are constantly out of date, the counterargument being that vulnerabilities are often found in new software versions. Without real statistics about security vulnerabilities over time it’s difficult to make an informed decision about software version policies.

4 months without proper patches to known vulnerabilities is very long. Previous versions of Android aren’t properly supported; they only receive a subset of patches, not nearly everything. In fact, not even Android 14 is currently getting full patches. At the time of writing, for a device to be properly patched, it must be on Android 14 QPR3. It’s why we put great care in porting everything over as quickly as possible. You don’t have to make guesses about vulnerabilities, you can simply look at all of the known vulnerabilities that haven’t been patched yet, or will never be patched, in previous Android versions. It’s not a matter of “what if”, it’s what’s actually happening.

Thank you, I missed that

7a would be the best balance between cod and expected support timeframe

Why would you import used devices from the US in the first place? People sell them in Europe too.

Doesn’t it seem that this problem is caused by Google not operating the markets in the same way?

Ty. Saving others some time:

Contactless payments work fine on GrapheneOS. It’s not like there’s something fundamentally incompatible about them. It just so happens that the most prevalent implementation (Gpay) requires a Google certified OS. The options right now are as follows:

People find alternatives (such as their bank) which provide this without using Gpay and don’t require a certified OS themselves.

This is implemented, which would at least temporarily allow people to use apps that require a certified OS on GrapheneOS: https://github.com/GrapheneOS/os-issue-tracker/issues/1986

Apps currently requiring a Google certified OS whitelist it as per https://grapheneos.org/articles/attestation-compatibility-guide (though it is of course very unlikely that Google themselves would do this)

But:

Barclays in the UK is only one example of contactless payments working without Google Pay, there are other banks in France for example for which we’ve had reports of similar contactless payment systems working. They exist; though I’m under no illusions that they’re prevalent, since I imagine from their POV, implementing Google Pay is much easier and maintainable.

On the spoofing CTS checks thing, I did not mean to insinuate that you or some other user would be the one to implement this. When I said “an option is for this to be implemented”, I meant the development team adding it to GrapheneOS. The issue is currently open and was opened by someone on the development team, so it’s not a feature that the team has ruled out. As with everything on GrapheneOS, though, the best way to approach it has to be determined, which can take time.

On your 3rd point, lobbying Google to whitelist GrapheneOS by using that guide is realistically never going to happen. Other OEMs that have to go through certification and pass CTS (compatibility test suite) which GrapheneOS doesn’t (because it adds things like new permissions which deviate from the compatibility goals that Android has set) would be outraged if that ever happened. In fact, I would wager that it would be a much more realistic scenario for someone to invest millions into funding a company that provides an alternative to Google Pay without puttng it behind a CTS check, rather than Google ever whitelisting GrapheneOS.

When someone says “contactless payments don’t work on GrapheneOS”, it’s not immediately clear to everyone that what is meant by that is “there aren’t good options for people to use right now” and I wouldn’t want someone to think that contactless payments are fundamentally incompatible with GrapheneOS, or that it breaks them somehow. Contactless payments via Gpay on GrapheneOS don’t work as of right now for the exact same reason why the McDonalds app in some countries (I kid you not) doesn’t. SafetyNet / Play Integrity API and their ctsProfileMatch and MEETS_DEVICE_INTEGRITY checks accordingly.