To also be pushed into the latest GrapheneOS release! View quoted note →

This is the first release of our Speech Services text to speech engine. This introduces text to speech in the OS for apps that call for OS TTS. Please feel free to test this as the first users so it can be improved for future releases. Please note that only English (US) is available for this first release but others will be implemented in the future. Since this is a text to speech engine and not a standalone application, you have to enable this in Settings > System > Language & Region > Speech > Text to speech output > Preferred engine. Eventually this will be default. If an app calls for OS text to speech, for example Organic Maps/CoMaps, it will use it there. View quoted note → #GrapheneOS

#GrapheneOS Speech Services, a high quality on-device text to speech engine built with open source models and training data is now available in the GrapheneOS App Store.

I think this is probably considered a hot take here but the quality of feature implementation matters far more than the implementation of a feature itself.

I have no comment on on-chain zaps. Likely won't use them or they just go sweep to the GrapheneOS Foundation. You can use Silent Payments for me though: sp1qqtdguesl4e507rt9m0pwfxvwxh2wf9c74pk9v4dclnf8agxe5vwq6qml9d4h6gz0vwf3dhgvznmvpu4z0gnfr33mr5wzmlcuxpqnturehvypr803

"Google Pixel with GrapheneOS: resistant to both BFU and AFU attacks on recent models (6[a] and newer). This is the strongest protection available on any Android device." View quoted note →

Another great article by Osservatorio Nessuno explaining the tech and methods behind phone unlocking tools, notably Cellebrite used by law enforcement and governments.

osservatorionessuno.org

Demystifying phone unlocking tools: A technical overview

Demystifying phone unlocking tools: A technical overview

GrapheneOS releases for Pixel 10a are mo longer experimental. Feel free to use Pixel 10a with it.

From Mullvad: "In contrast, #GrapheneOS, a security-focused Android-based OS, quickly [already] patched the issue in its codebase."

Mullvad VPN

Any app on recent Android versions can leak certain traffic | Mullvad VPN

A recently discovered bug in Android 16 allows any app to leak traffic outside the VPN tunnel.

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. 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. 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. 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:

Troubleshoot reCAPTCHA Mobile Verification - reCAPTCHA Help

Important: Mobile verification for Google Cloud

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. 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. 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 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 Linux or FreeBSD instead. You'll just be more locked out. 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. It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source. Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them. Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security. reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that. This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere.

This week, we patched a VPN leak in Android that was reported to Google but was ignored. Here is some coverage about that:

CyberInsider

GrapheneOS fixes Android VPN leak Google refused to patch

GrapheneOS has released a new update that fixes a recently disclosed Android VPN bypass flaw capable of leaking a user’s real IP address.

Here is the original vulnerability report:

The Tiny UDP Cannon: An Android VPN Bypass

An unprivileged Android app can leak the user

CVE-2026-0073 is a Critical severity Remote Code Execution (RCE) vulnerability included as the only vulnerability fixed in the May 2026 Android Security Bulletin. #GrapheneOS first shipped the patch in our 2026030501 security preview release early on March 5th. It also isn't nearly as severe as it sounds. This was a bypass for TLS client certificate authentication in the Android Debug Bridge (ADB) for the Wireless debugging feature. It's only relevant to users enabling developer options, enabling Android Debug Bridge and then enabling Wireless debugging. Wireless debugging is disabled on reboot. Our security preview releases are recommended in the initial setup wizard via a dedicated page with toggle that's enabled by default. Existing users who weren't shown the page received a notification at boot opening a similar page with a save button. It reappears until a choice is made either way.

GrapheneOS isn't vulnerable to the 3 recently disclosed Linux kernel vulnerabilities named Copy Fail, Copy Fail 2 and Dirty Frag. Current Android Open Source Project SELinux policies block exploiting all 3 bugs. Standard AOSP GKI kernel configuration also has 2/3 of the vulnerable features disabled. Attack surface reduction via fine-grained SELinux policy rules and stripping out unused kernel features via kernel configuration goes a long way to protecting against vulnerabilities. There's also seccomp-bpf for various standard sandboxes but most of the attack surface reduction is via SELinux. AOSP uses SELinux to allowlist ioctl commands for drivers, permitted socket types, etc. in a fine-grained way. It strictly controls a lot of functionality prone to vulnerabilities including user namespaces and io_uring which aren't allowed to be used by apps or nearly any of the base OS processes. These kinds of issues are rare and attack surface reduction is the best way to defend against them. #GrapheneOS does additional kernel attack surface reduction but in these 3 cases it's enough to have modern AOSP GKI kernel and SELinux policies. We also greatly improve generic exploit protections. Local privilege escalation vulnerabilities in the Linux kernel are very common. However, the vast majority are memory corruption bugs rather than these memory-related logic errors. We defend against the memory corruption bugs with hardware memory tagging, zero-on-free and similar generic defenses. Linux has a massive amount of code for the core kernel and drivers for the hardware. All of the code runs with full privileges with no isolation. In a microkernel, each of these 3 recent vulnerabilities would have been in isolated processes. Virtualization will have a major role in addressing this. Despite these not being traditional memory corruption, a memory safe language with a better type system would definitely help. Containing low-level handling of memory to a much smaller portion of the kernel and mostly using safe abstractions for networking, device drivers, etc. would help a lot. Linux has a relentless flood of severe memory corruption bugs being discovered. Nearly all exploit chains for Linux-based systems by commercial and government exploit developers use Linux kernel memory corruption bugs. It's a lot harder to make very portable and reliable exploits for those bugs. A lot can be done to further reduce Linux kernel attack surface in GrapheneOS and much better generic memory corruption exploit protections can also be developed. However, it clearly needs to be replaced. Hardware-based virtualization on smartphones keeps getting better and has a major role to play.