Notices by GrapheneOS (grapheneos@grapheneos.social)

https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

Android's security policy for the past several years has been to backport patches for Critical and High severity Android vulnerabilities to the past 3 major yearly releases. Moderate and Low severity patches including most fixes for privacy weaknesses have required upgrading to the latest releases.

Google recently informed OEMs of greatly reduced security support for older releases of Android. For the vast majority of discovered vulnerabilities, only Critical severity issues deemed to be an imminent risk will be backported at all and only to the most recent 2 major yearly releases (16 and 17).

GrapheneOS opposes authoritarianism. It's a core part of why we're building privacy technology as part of a non-profit open source project. We're opposed to it regardless of whether it comes from left, center or right. The flood of people lying about what we believe and have said won't change this.

Leave a 1 star review for Volkswagen's apps on the Play Store asking them to stop banning GrapheneOS. Explain it's a far more secure operating system and fully possible for them to verify the hardware, OS and their app on it if they insist on doing it. It's far more secure than anything they allow.

Hyundai and Kia added official GrapheneOS support to their apps months before Volkswagen banned GrapheneOS:

https://discuss.grapheneos.org/d/31697-myhyundai-app-has-official-grapheneos-support

Pressure from Volkswagen customers on them can achieve the same thing. There's no legitimate reason to ban GrapheneOS so they'll undo it with pressure.

Today is the official release day for Android 17. We've already fully ported GrapheneOS to Android 17 and are in the process of pushing the code to our public repositories. We're building a final official release based on Android 16 QPR2 today and we'll do an initial Android 17 release tomorrow.

The first public release of GrapheneOS Speech Services is now available in our App Store. After installing it, it can be activated as a text-to-speech service by tapping it in Settings > System > Language & region > Speech > Text-to-speech output > Preferred engine and approving it in the dialog.

@garrett Most banking apps still work on GrapheneOS but Play Integrity API adoption is expanding and it's nearly impossible to convince an app to stop using it once they've started. We've only successfully convinced a couple apps to stop. We've convinced a lot more apps to start permitting GrapheneOS by using the Android hardware attestation API as an alternative which can be used to permit arbitrary hardware and operating systems but that's still very problematic including for GrapheneOS.

@garrett We provide documentation at https://grapheneos.org/articles/attestation-compatibility-guide on how apps can use the Android hardware attestation to permit GrapheneOS and other hardware / operating systems which aren't certified by Google. This API supports permitting alternate roots of trust and non-stock operating systems. We use new signing keys for each new device model so new devices won't be listed without them updating it and their list won't include alternate builds of GrapheneOS. Apps should not be doing this at all.

Apple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too.

Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition.

Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web.

The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it.

Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems:

https://support.google.com/recaptcha/answer/16609652

Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more.

Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web.

Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive.

Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it.

Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on FreeBSD instead. You'll just be more locked out.