Notices by GrapheneOS (grapheneos@grapheneos.social)

App developers can implement support using standard hardware-based attestation and allowlist the GrapheneOS signing keys if they insist on checking device integrity. There's a guide for this at https://grapheneos.org/articles/attestation-compatibility-guide. There's no good excuse for only permitting a device/OS licensing GMS.

Most apps using the Play Integrity API are enforcing the device integrity level. This enforces having a device licensing Google Mobile Services with the stock OS. It has no issue with a device behind on patches by a decade. Strong integrity level checks for the same thing via hardware attestation.

We've implemented a system for notifying users when apps use the Play Integrity API. This will help users determine which apps are banning using a non-stock OS. Some of these will still work if they only enforce basic integrity rather than requiring a Google certified device running the stock OS.

Using Play Integrity is an incredibly anti-privacy and anti-security practice despite being wrongly portrayed as a security feature. The notification will include a link for leaving a rating and review for the app via sandboxed Play Store to make it very convenient for people to send complaints.

@b83c911407c576004346154f310779d2c0ce7f0ae6a5a02620cbec2e3735d2b2 We don't have a Nostr account yet. This is our Mastodon account being bridged by someone else.

@b83c911407c576004346154f310779d2c0ce7f0ae6a5a02620cbec2e3735d2b2 Here's where that post actually came from:

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

It must be doing a good job bridging to Nostr because we regularly get replies where people think we have a Nostr account. It doesn't do a great job showing us what people are saying on Nostr though. We can only see messages replying to us through what they bridge to us, not earlier conversations in threads before the bridged account was mentioned.

An issue was filed on our Vanadium issue tracker about a potential Chromium WebRTC privacy issue. It was filed to track our process of determining whether we needed to do something about it with a privacy enhancement in GrapheneOS. We ended up deciding not to make a change to it.

@ntnsndr /e/OS is Android with a massive reduction in security and their own privacy invasive, non-end-to-end encrypted services instead of Google services. iPhones provide far better privacy and security than Murena devices. These lack basic industry standard exploits mitigations and other security features, still integrate Google services with privileged access and do not take privacy/security seriously at all. Not having Google Play isn't enough for privacy.

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

@jorge @ntnsndr

GrapheneOS and /e/OS are very different. GrapheneOS is a hardened OS with substantial privacy/security improvements:

https://grapheneos.org/features

/e/OS is not a hardened OS.

They're always on a very old release with partial support. Android 15 QPR1 is needed for full privacy/security patches. Only patches for issues deemed High/Critical priority are backported to older Android releases, and most privacy patches are not backported.

They also lose a bunch of security features.

@jorge @ntnsndr

Compatibility with Android apps is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:

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

Can run nearly all Play Store apps on GrapheneOS, but not /e/OS with the far more limited and less secure microG approach.

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

@jorge @ntnsndr

The eylenburg comparison has a useful comparison of how some of the default Android Open Source Project connections to Google services and GNSS vendors are handled. That's not a full list of default connections and most of the operating systems including /e/OS add a bunch of additional connections, many of them problematic themselves.

Aside from that, moving to a different set of privacy invasive services without end-to-end encryption doesn't really protect people's privacy.

@jorge @ntnsndr

iPhones provide better privacy and security than /e/OS including for their services which largely support end-to-end encryption with the Advanced Data Protection feature for iCloud.

/e/OS has far worse privacy from apps than iOS. With /e/OS, you cannot give apps access only to certain contacts or certain media/storage if they insist on demanding access to all of it. There are a bunch of other unaddressed privacy weaknesses, especially due to the older Android version.

@jorge @ntnsndr

iOS does not have basic exploit protections and security features intact. They do not properly sign their releases, do not use have a secure update system, do not use verified boot, etc. They aren't taking privacy or security seriously at all. Industry standard security features are missing or even outright disabled. The starting point of LineageOS is where many of these issues come from, but it's a further step down from there for security.

@aracnus @tarcisiosurdi Play Integrity API exists to block a service working on a device that's not licensing GMS from Google and complying with their rules which largely have nothing to do with security. They do have some basic security requirements but providing security patches isn't one of them and the Play Integrity API does not require it. A device with no patches for 8 years is allowed but not GrapheneOS which is a hardened OS that's far more secure than anything they permit.

@aracnus @tarcisiosurdi GrapheneOS supports running Google apps including Google Play as regular sandboxed apps. It's unfortunate lots of apps depend on them but we don't think that problem is getting worse. There are more and more high quality open source apps not depending on it. Android has a huge open source app ecosystem. However, Google should not be allowed to block their apps or especially third party apps working on operating systems that are not licensing Google Mobile Services (GMS).

Google's Play Integrity API is not a security feature but rather it pretends to be one. Both Apple and Google are failing to protect their users against real world commercial exploit tools. Banning using one of the only options people have for better protection is anti-security.

@iviyohane Google's behavior has already been found to be illegal and they're unlikely to start walling off their own services in a completely indefensible way. They're already going to be facing serious consequences for what they're doing. It's unfortunate they're doubling down on pretending the Play Integrity API has anything to do with security and convincing more and more apps to adopt it though. They think they'll get away with it because they claim it's about security but it's clearly not.

Unfortunately, Revolut has banned GrapheneOS users from logging into the app because of an incorrectly implemented device integrity check based on the anti-competitive Play Integrity API. Our users need to put pressure on apps like this to get them to whitelist GrapheneOS.

How you can help solve it:

1) Open a support request explaining they've incorrectly banned a secure operating system with a link to https://grapheneos.org/articles/attestation-compatibility-guide with how to fix it.
2) Contact their management on LinkedIn and other platforms with the same thing.
3) Play Store review.

United States v. Google LLC (2020) recently found that Google's Android partner system and therefore the Play Integrity API based on it is illegal.

We're in active contact with the EU Commission about the Play Integrity API and are hopeful they're going to do something about it.