GrapheneOS [Unofficial]

WebRTC is a peer-to-peer communications protocol for web sites and therefore causes numerous privacy issues through making direct connections between participants. By default our Vanadium browser disables the peer-to-peer aspect by only using server-based (proxied) connections.

Vanadium provides a user-facing setting at Privacy and security > WebRTC IP handling policy.

From least to most strict:

DefaultDefault public and private interfacesDefault public interface onlyDisable non-proxied UDP

For Vanadium, "Disabled non-proxied UDP" is the default.

The tracking technique described at https://arstechnica.com/security/2025/06/meta-and-yandex-are-de-anonymizing-android-users-web-browsing-identifiers/ is prevented by Vanadium's default "Disabled non-proxied UDP" value. It's also prevented by "Default public interface only", which does permit peer-to-peer connections but won't try to use the loopback interface for it.

We have a list of most of the features provided by Vanadium at https://grapheneos.org/features#vanadium. There are dozens of additional privacy and security features planned along with data import/export and improved support for system backups. It takes time to implement these things properly.

Vanadium doesn't have billions or even millions of users which limits our ability to prevent fingerprinting. We plan to address this by launching it for use outside GrapheneOS including publishing it through the Play Store. We want to implement more of the planned features first.

For the non-WebRTC issue being abused by Yandex, Chromium 137 shipped a fix for it behind a feature flag that's being gradually rolled out. We can roll this out to 100% of Vanadium users through a Vanadium Config update. We can start Alpha testing for that new flag later today.

Vanadium Config version 95 enables protection for local networks and loopback. The user interface for making per-site exceptions isn't available for Android yet. The overall feature can be disabled via chrome://flags if for some reason someone needs that functionality right now.

Changes in version 137.0.7151.72.0:

• update to Chromium 137.0.7151.72
• disable using in-browser PDF Viewer by default since it's much less secure than our own PDF Viewer, but we plan to add a toggle to enable it in a future release for people who want it regardless

A full list of changes from the previous release (version 137.0.7151.61.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

This is an early June security update release based on the June 2025 security patch backports since the yearly Android Open Source Project and stock Pixel OS release scheduled for this month hasn't been published yet.

Tags:

• 2025060200 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025060100 release:

• full 2025-06-01 security patch level
• System Updater: temporarily revert notification protection due to upstream Android UI issues for this feature with privileged apps (we still plan to do this but it will need to wait until we resolve the OS issue)
• remove Chunghwa Telecom and Netlock Certificate Authorities (CAs) for fresh installs (will need another change to trigger removal for existing installs) based on the decision by the Chrome Root Store (this does not impact Vanadium since it uses a more sophisticated browser root store rather than the OS root store and will distrust certificates from these CAs not added to Certificate Transparency logs before 2025-08-01 to avoid website compatibility issues)

Tags:

• 2025060100 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025052800 release:

• Media Provider: expand our existing protection against CVE-2024-50089 which is still not addressed upstream (we added generic hardening in 2022 as a prerequisite for Storage Scopes which along with fixing information leaks still unfixed upstream blocked exploiting CVE-2024-50089 for the common cases of not granting permissions, granting media permissions or using our Storage Scopes feature but we didn't fully cover "All files access" or the legacy API level equivalent when not using Storage Scopes)
• System Updater: prevent disabling overall notifications due to lack of a use case and many users doing it by accident, but continue allowing disabling the individual notification channels other than the reboot notification
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.92
• Messaging: update to version 8
• Vanadium: update to version 137.0.7151.61.0

Notable changes in version 8:

• associate contact URIs with notifications to fix starred contacts bypassing Do Not Disturb
• respect "Incoming messages" notification settings when creating notification channels for conversations
• prevent conversation deleted toast spam
• update Guava library to 33.4.8
• update AndroidX RecyclerView library to 1.4.0
• update Android Gradle plugin to 8.10.1
• update Gradle to 8.14.1
• update Kotlin to 2.1.21
• update Android build tools to 36.0.0
• migrate to AndroidX Nullable annotations

A full list of changes from the previous release (version 8) is available through the Git commit log between the releases.

Changes in version 137.0.7151.61.0:

• update to Chromium 137.0.7151.61

A full list of changes from the previous release (version 137.0.7151.44.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Our Contact Scopes and Storage Scopes features provide essential privacy functionality that's missing on standard Android. Scopes are a replacement for the standard contacts, storage and media permissions. We offer these as an alternative when apps request access to any of those.

When you enable Contact Scopes or Storage Scopes, GrapheneOS makes the app believe you've granted the requested permissions. However, it doesn't receive access to any more additional data not created by itself. Most apps work by simply enabling these without doing anything more.

For Contact Scopes, you can choose to give the app read access to a subset of the data for specific contacts. For more convenience, we support grouping contacts together and granting access to a group. It's very useful even without granting access to anything to pretend you have.

Storage Scopes functions differently depending on which permissions are requested. It acts as if the permissions were granted but only allows accessing files created by the app itself and doesn't provide additional info on files created by other apps compared to not enabling it.

Adding scopes after enabling Storage Scopes is only needed to provide access to files created by other apps. For example, if you regularly create files in a directory with both app A and app B and access them with app C, a scope can be granted to app C to access files from there.

Contact Scopes and Storage Scopes work around the fact that most app developers do not use the system contact picker, file picker, etc. but rather request broad access via permissions. We're going to be adding more similar features providing an alternative for more permissions.

Following our port to Android 16, providing similar features for Camera, Microphone and Location will be among our top priorities.

For Location, it will allow setting a per-app location instead of granting the permission. Android has Mock Location already, but it's a global.

For Camera, you'll be able to set a picture or video file to loop for the app as an alternative to granting the permission. For Microphone, you'll be able to set an audio file to loop for the app.

We plan to expand this approach to other permissions further in the future too.

We recommend not granting storage or media permissions to user installed apps. Storage Scopes should be a full substitute for those already.

Contact Scopes is not quite a full substitute yet since it can't permit write access or shared accounts, but we plan to expand it later.

Storage Scopes can even be used as a full replacement for Android's file manager permission ("All files access") giving access to the entire home directory. Android acknowledges that is dangerous and tried to restrict access to a couple special use directories but nothing else.

Android's only restrictions on apps granted file management access are not allowing access to Android/data and Android/obb. Android/data is an alternative to internal app storage where users get file access. Android/obb is a long time deprecated way to distribute large files.

Due to an upstream Linux kernel vulnerability, Android's attempt at restricting access to Android/data and Android/obb for the file management permission didn't work (https://nvd.nist.gov/vuln/detail/CVE-2024-50089). A fix was implemented in the Linux kernel, then reverted due to breaking compatibility.

Fix:

https://github.com/torvalds/linux/commit/5c26d2f1d3f5e4be3e196526bead29ecb139cf91

Revert:

https://github.com/torvalds/linux/commit/231825b2e1ff6ba799c5eaf396d3ab2354e37c6b

CVE assigned to this (CVE-2024-50089) was then rejected, since the Linux kernel project took over managing Linux kernel CVEs and only allows CVEs for their backported patches, not as a vulnerability tracking system.

Fixing this outside the kernel is problematic. Most approaches will end up having bypasses. Android has struggled to do that and seems unwilling to temporarily apply a kernel patch. Some other AOSP-based projects are adopting an approach to this we don't believe is correct.

Android 16 appears to have an attempt at a full fix in userspace. "All files access" grants will still be dangerous and privacy invasive.

Storage Scopes is our way of making the best out of maintaining compatibility with a messy coarse permission model with odd special cases.

In Android 4.4, support was added for apps using the system file picker to have users choose files for them. In Android 5, it was extended to directories. Adoption of this was extremely poor until they began coercing apps to use it. There's now also forced photo picker support.

Our Storage Scopes feature is not a restriction but rather a better alternative to granting storage and media permissions. It's better if apps support the system file picker. Apps prefer demanding bulk data access over that. On GrapheneOS, you can say no and still use the apps.

Our Storage Scopes feature includes additional hardening which caused the serious Linux kernel CVE-2024-50089 vulnerability to be much less severe with GrapheneOS due to mostly limited the impact to the "All files access" permission rather than cases without that being granted.

Tags:

• 2025052800 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025052000 release:

• disable anti-competitive code being injected by the Play Store into apps choosing to enable "App integrity > Automatic protection" when there's a valid Play Store source stamp signature (proving that it's an unmodified app from the Play Store, so we aren't disabling an integrity check) since it prevents using the apps on GrapheneOS when apps also choose to enable "App integrity > Store listing visibility" with either the "Device integrity checks" or "Strong integrity checks" values enforcing having a device licensing Google Mobile Services and running the stock OS (circumventing this is protected by the DMCA exemption for jailbreaking)
• Private Space: fix further issues with quiet/locking state changes in secondary users
• extend NFC auto-turn-off to work when logged into a secondary user
• kernel (6.6): update to latest GKI LTS branch revision
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.140
• Vanadium: update to version 137.0.7151.44.0
• Vanadium: update to version 137.0.7151.44.1

Changes in version 137.0.7151.44.1:

• fix upstream picture-in-picture regression in Chromium 137

A full list of changes from the previous release (version 137.0.7151.44.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

We're looking into using https://github.com/k2-fsa/sherpa-onnx to provide built-in text-to-speech and speech-to-text to greatly improve the out-of-the-box accessibility of GrapheneOS for blind users. We already have a screen reader included via our fork of the open source variant of TalkBack.

To have text-to-speech functioning out-of-the-box, we can choose one of the models with open source training code and data as the default to be included within the OS. We wouldn't need to include anything that's not truly open source. It's the only reasonable option we've found.

There are over 100 models for 40 languages. Some research is going to be required to figure out which of the English ones are fully open source (open training data and code) and then which of those works best for basic text-to-speech to have as the default bundled in the OS.

If we had text-to-speech support included in GrapheneOS, we could also provide an automatic captions feature.

We'll need to do a basic review of the code for text-to-speech, speech-to-text, shared code and any other parts we decide to use. We'll need at least a minor fork of it.

We want to stick to a model with open source training code/data for what we bundle, so we're likely not going to be able to use one of the best options by default. Having a tolerable open source model by default with the option to switch to great "open" models seems good enough.

We could use help narrowing down which of the available English models with open training data would be best (least bad) for basic text-to-speech usage including for TalkBack. We could also collect feedback somewhere on which ones people think are best overall across languages.

In order to provide better support for blind users, we maintain a fork of the open source TalkBack app fixing serious issues with it, modernizing it and making the builds reproducible. One of the goals of making our own Setup Wizard has also been integrating TalkBack support.

Google unfortunately doesn't publish the source code for each stable release of TalkBack as they do for Android itself. The open source release of the app lags significantly behind. It also has a bunch of missing and broken features. We plan to gradually improve this situation.

In order to use GrapheneOS, blind users need to successfully install the OS and set up the device to be usable with a screen reader. This is an area we've been thinking about and working on improving for a while. Our new Setup Wizard provides a better base for integrating this.

The first barrier to someone using GrapheneOS without sight is installing the OS. We've done what we can to make our web installer as accessible as possible (https://grapheneos.org/install/web). However, users need to interact with the device's firmware interface which the user can see.

Due to the inaccessible firmware user interface, it's difficult to perform the installation correctly and safety, particularly confirming unlocking and then confirming locking. Confirming the verified boot key matches after installing/locking would require OCR on another device.

The next issue is the Android Open Source Project no longer includes a text-to-speech app. Pico TTS used to be included in AOSP but was not what Google Mobile Services devices use. It was quite primitive, awful to use and AOSP removed it after security issues were found.

We've wanted to include a text-to-speech app and bundle a language pack to have it working out-of-the-box for a long time. We could then add a shortcut for enabling TalkBack in our new Setup Wizard to make things accessible from the start of the post-install setup process.

To provide what we need, the TTS app needs to be built into the OS, enabled and set up to work by default without configuration. It doesn't do any good if you need to connect to a network and download a language pack. It also needs to work Before First Unlock via Direct Boot.

Since it will be enabled by default, security is quite relevant. It shouldn't be a bunch of C++ code without a modern coding style, use of sanitizers, decent tests, etc. It needs to be actively developed and properly maintained. This is why Pico TTS had to be removed from AOSP.

GrapheneOS is intended to be a drop-in replacement for the Android Open Source Project usable by companies to make all kinds of products. Due to this, we avoid non-commercial usage licenses. Lots of the language packs for TTS implementations have non-commercial usage licenses.

We also avoid including GPLv3 code in the base OS since it would add restrictions on how it can be used. We do add new GPLv2 licensed code. This doesn't mean we have issues with using GPLv3 code or making forks of GPLv3 projects, we just don't bundle it within GrapheneOS itself.

Neither eSpeak NG or RHVoice meets our security expectations (piles of problematic C and C++ code) and both have licensing issues. Both were previously also missing Direct Boot support to function Before First Unlock, but we requested it from both and eSpeak NG implemented it.

There were previously no good options available. Things have changed and there are multiple open source text-to-speech implementations which could be turned into a suitable Android app and integrated into the OS. This involves significant work and we haven't gotten to this yet.

We have hundreds of planned features. We've been working on some features for months or even years. We try to focus on features which would provide the most overall benefit to our users with a focus on improving privacy, security, compatibility and usability. It's subjective.

For example, built-in support for network location was a feature we wanted to integrate for years. Last year, we made it a top priority, and assigned a developer to solely work on it, so it got done. This is still being worked on to add cellular fallback and full offline support.

Changes in version 137.0.7151.44.0:

• update to Chromium 137.0.7151.44

A full list of changes from the previous release (version 136.0.7103.125.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

A growing number of apps are using the Play Integrity API to enforce installation from the Play Store. This is clearly highly illegal anti-competitive behavior. It doesn't impact GrapheneOS users installing apps with the sandboxed Play Store but does impact other install sources.

This is being done alongside Google recommending app developers forbid installing their apps from the Play Store on operating systems not licensing Google Mobile Services. The combination of these feature ends up blocking users from easily using the apps without modifying them.

We're going to add a secure way of working around this without breaking the app source security model. We'll be adding support for having the OS automatically verify the Play Store signing metadata and then inform Play services those apps were installed from the Play Store.

It's worth noting Android has a standard hardware attestation API for verifying the hardware, firmware, OS and app. This supports alternate roots of trust and non-stock operating systems if apps choose to support it. Apps could perform stronger checks while allowing GrapheneOS.

Android's hardware attestation API has anti-competition issues due to the official verification libraries hard-wiring the Google roots and encouraging only permitting the stock OS. However, it does fully support any other OS with verified boot and can be used with other root CAs.

Google's Play Integrity API is quite different and only supports verifying devices licensing Google Mobile Devices with the stock OS. It has support for enforcing installing apps from the Play Store. None of this has anything to do with security. It's purely anti-competitive.

Google Play Integrity permits highly insecure devices with years of missing High/Critical severity security patches. They pretend any device licensing Google Mobile Services is secure while running the stock OS and anything else is insecure. This is a lie to lock out competition.

There's no security value to enforcing using devices licensing Google Mobile Services. The vast majority of those devices are highly insecure. Software-based attestation (device integrity) is also highly insecure and easy for attackers to bypass. This is only hurting competition.

Hardware-based attestation can be secure, but the way the Play Integrity API uses it is also highly insecure. It can be bypassed via leaked keys from the most insecure Android devices in the ecosystem. Secure way to use it is pinning, not trusting everything chaining to a root.

Even if apps insist on doing these kinds of integrity checks, they can still permit GrapheneOS. We provide a guide on verifying GrapheneOS via hardware attestation at https://grapheneos.org/articles/attestation-compatibility-guide. They can still fall back to Play Integrity API for insecure devices without this.

Multiple prominent banking apps in Europe have already implemented support for GrapheneOS via hardware attestation. The pace of apps adopting the Play Integrity API is unfortunately currently faster than apps adding support for GrapheneOS. This is due to Google marketing it.

If you run into apps banning using GrapheneOS with Play Integrity, make a Play Store review with no links asking to stop banning a more secure OS. Next, make a customer support request linking https://grapheneos.org/articles/attestation-compatibility-guide. Multiple apps have permitted GrapheneOS due to these efforts.

We still need help getting early access to Android 16 sources prior to the stable release in June. Every mainstream Android OEM has it. We're currently spending significant time on reverse engineering Android 16 Beta releases. It's a huge waste compared to having what we need.

Tags:

• 2025052000 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025051900 release:

• Private Space: set correct state on user start or stop for secondary users
• Private Space: make sure nested profiles in secondary users have their storage put at rest when the parent profile's session is ended
• Keyboard: remove dedicated language switch key from the phone layout since it's already shown by the OS itself and uses up too much space with the emoji key already next to the space bar

Tags:

• 2025051900 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025050700 release:

• add NFC auto-turn-off setting to go along with the existing addition of Wi-Fi and Bluetooth auto-turn-off settings
• Private Space: add new setting for disabling delayed locking of storage to make locking work like secondary user end session feature we enable, similar to the toggle we add for disabling secondary users running in the background (standard Private Space doesn't work this way to keep fingerprint unlock available after it's locked/stopped)
• Private Space: add new setting for blocking sharing the clipboard to and/or from the parent profile and other nested profiles within it
• Private Space: add support for the Install available apps feature we currently enable to support installing apps available in the Owner user to secondary users
• Private Space: add support for secondary users including all standard features with the exception of auto-locking support since our implementation of that is too complex/invasive to properly review and test while we're focused on Android 16 porting
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.138
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.89
• Keyboard: move the emoji key to the left of the space bar for the phone layout instead of putting it behind a long press or replacing the enter key with it when put into the emoji mode by apps like AOSP Messaging
• Keyboard: stop replacing the emoji key with the .com key for the email and URL input types
• Vanadium: update to version 136.0.7103.125.0
• add support for testing Android 16 Beta 4.1 feature flags for development builds

Similar to iOS lockdown mode, Android 16's Advanced Protection feature is misguided. It adds security features exclusive to it which require using all of the other features. This prevents people using new security features if they need to avoid 1 feature.

https://security.googleblog.com/2025/05/advanced-protection-mobile-devices.html

Most of the features already existed. The new ones are cloud-based intrusion logging, inactivity reboot (hard-wired to 72 hours), a new mode of USB protection and disabling auto-connect to a small subset of insecure Wi-Fi networks. Production MTE support is also essentially new.

GrapheneOS added locked device auto-reboot in July 2021. We proposed it to Google for Android in January 2024 as part of reporting exploitation by forensic data extraction companies. They implemented several of our other proposals, but not this until iOS added it in October 2024.

Both GrapheneOS and iOS enabled lock device auto-reboot by default, at 18 and 72 hours respectively. It can be set between 10 minutes and 72 hours on GrapheneOS along with having an opt-out. Putting this behind a feature barely anyone will use makes the real world impact minimal.

The Advanced Protection mode support for the ARM Memory Tagging Extension (MTE) is misleading. It won't be using it for the kernel, most of the base OS or 99.999999% of apps. It will only be enabled for certain base OS components and a tiny minority of apps explicitly enabling it.

Certain apps like Molly opt-in to MTE, but this doesn't really do anything since so far Android isn't providing any production MTE support. This tiny minority of apps enabling the feature will finally have it on certain devices for < 0.001% of users using Advanced Protection.

Chrome / Chromium provides a very misleading "V8 Optimizer" toggle which contrary to popular belief does not disable the Just-In-Time compiler and therefore cannot block dynamic code generation. It's not a default JIT disable like iOS lockdown mode or default GrapheneOS.

Chrome's "V8 Optimizer" toggle started out as a JIT toggle. However, Chromium's WebAssembly support currently requires JIT and they quickly crippled the setting in an emergency update. It now only disables the highest 2 tiers of the JIT, so a lot of the security value is missing.

Microsoft implemented a simple WebAssembly interpreter for Microsoft Edge as part of their earlier JIT disable feature. Microsoft submitted their WebAssembly interpreter to Chromium and got it merged after a long time. Chrome / Chromium doesn't use it, maintain it or test it.

Since they aren't maintaining or testing it, other Chromium-based browsers can't use this feature without taking on the responsibility of maintaining it. Google could easily start maintaining it to fix their very misleading "V8 Optimizer" toggle but so far has neglected to do so.

It's entirely possible to provide the new security features standalone and then group them together in a mode enabling all of them, but with the option to disable certain features. That could then show up as a warning that the mode isn't fully enabled. Instead, they copied iOS.

Part of enabling Android's Advanced Protection feature is disallowing users from installing apps from outside of the Play Store. This can currently be bypassed using Android Debug Bridge via developer options, but that's awful for security and they'll likely crack down on it too.

Apps coming from the Play Store doesn't make them trustworthy, safe or secure. Most malware apps on Google Mobile Services devices are installed from the Play Store. Similarly to the Play Integrity API, it's Google reinforcing their monopolies with security as an excuse for it.

Google was already blocking competing app stores with their Advanced Protection Program required to properly secure a Google account, but now they're tying Android device security to this. Want proper encryption security via inactivity reboot? You cannot use competing app stores.

Google has taken a similar path with the extraordinarily anti-competitive Play Integrity API, which disallows using any hardware or OS not licensing Google Mobile Services (GMS). Licensing GMS forces shipping Google apps with invasive access and limits allowed changes to the OS.

OEMs licensing GMS are blocked from including many features in GrapheneOS. They obviously can't provide sandboxed Google Play, but less obviously can't provide our Storage Scopes, Contact Scopes, Sensors toggle, Network toggle, much broader/better MTE integration and far more.

Changes in version 136.0.7103.125.0:

• update to Chromium 136.0.7103.125
• enforce certificate transparency in the same way as Chrome branded builds since it was disabled for Chromium release builds based on the assumption that Chromium forks won't keep up with updates (Vanadium ships major updates on the same day and ships certain updates early)
• disable network time fallback support for certificate errors, etc. since GrapheneOS provides very reliable HTTPS network time not depending on either UDP or cellular working
• disable more optimization and text safety classifier feature flags to make sure none of it is ever used
• fully disable support for the Google password leak detection service and hide the no-op toggle for it

A full list of changes from the previous release (version 136.0.7103.87.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Modern Android has standard support for granting one-time access to Camera, Microphone and Location. We highly recommend using this for apps requesting these permissions. It revokes access a minute after the app stops being used. This is much nicer than using the global toggles.

GrapheneOS supports automatic timeouts for Wi-Fi and Bluetooth with a pending pull request from a contributor to add this for NFC. Users often request similar features for Camera, Microphone and Location but it would be kept active by any apps granted access continuing to use it.

Android's existing approach is far superior for users who are actively choosing to use it by leaving the toggle on "Ask every time" and then selecting "Only this time" each time the app asks for access instead of "While using the app". It's much better than using global toggles.

GrapheneOS adds Storage Scopes and Contact Scopes as a replacement for granting the Contacts permission or the various storage/media permissions. We have similar features planned for Camera, Microphone and Location. Android has global Mock Location, but we want a per-app feature.

We can still consider the regular request we get for adding timeouts to the global toggles. However, we don't want to further encourage granting persistent access to apps with reliance on the global toggles to disable it. Apps using it preventing a timeout would also be an issue.

Support for setting a per-app video stream as an alternative to granting Camera access, a per-app audio stream as an alternative to granting Microphone access and a per-app location as an alternative to granting Location access will be implemented after our port to Android 16.

See https://grapheneos.org/usage#contact-scopes and https://grapheneos.org/usage#storage-scopes to information on our existing Contact Scopes and Storage Scopes features. You can also already use the standard Android Mock Location but our per-app feature will be simpler and much more convenient than the global one.

We've improved how we direct connections to GrapheneOS servers by using anycast to fill in missing GeoIP data. This should reduce service latency and improve download bandwidth for many users in the western US and especially with certain VPN providers.

https://github.com/GrapheneOS/ns1.grapheneos.org/commit/fd37a0c4434575a241840a9f9e51d5bffe31b498

Here's an example of how we use anycast to send traffic to the nearest nameserver:

https://ping.pe/ns1.grapheneos.org

This shows how we respond with an IP address based on GeoIP + anycast node:

https://dig.ping.pe/grapheneos.org:A:ns1.grapheneos.org

With these examples, only 1 is off (UK server geolocated in US).

You can compare those to see that does a great job:

https://ping.pe/51.222.156.101 https://ping.pe/209.141.35.164 https://ping.pe/54.37.41.188 https://ping.pe/51.79.160.50

Note ping.pe looks up a domain name in 1 location, then pings it everywhere, so it's misleading for a domain.

Improving update download speed is the biggest benefit. One of the network services we provide to GrapheneOS users is secure network time where low latency improves accuracy. See https://grapheneos.org/faq#default-connections, https://grapheneos.org/faq#other-connections and https://grapheneos.org/features#network-location for the other services.

The way we've set up our server infrastructure means that any single provider having downtime won't take down our website, updates or network services. We can scale it up across providers instead of a specific one. It's also extremely cost effective to save money for development.

We noticed Hardenize (https://www.hardenize.com/) isn't compatible with Let's Encrypt certificates using the recently launched tlsserver profile. See https://letsencrypt.org/docs/profiles/ for details, it mainly drops non-SNI client support. Maybe we have a contact who can get it fixed quickly.

We deployed tlsserver for our services to prepare for shortlived:

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

We didn't deploy it for SMTP because too many mail servers likely still lack SNI support. For SUPL, we did a hybrid deployment until we're ready to drop 4th/5th gen Pixel support.

Tags:

• 2025050700 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025050500 release:

• full 2025-05-05 security patch level
• rebased onto BP1A.250505.005.D1 Android Open Source Project release
• Vanadium: update to version 136.0.7103.87.0

This is an early May security update release based on the May 2025 security patch backports since the monthly Android Open Source Project and stock Pixel OS release scheduled for this month hasn't been published yet.

Tags:

• 2025050500 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025050300 release:

• full 2025-05-01 security patch level

In anticipation of Let's Encrypt dropping Must-Staple support on May 7th and OCSP 3 months later, our services previously using OCSP stapling and Must-Staple have been moved to the Let's Encrypt tlsserver profile made publicly usable a couple weeks ago.

https://community.letsencrypt.org/t/removing-ocsp-urls-from-certificates/236699

The tlsserver profile drops support for OCSP early along with various legacy features. The upcoming shortlived profile is based on the tlsserver profile with validity reduced from 90 days to 6 days, so we can now smoothly migrate to shortlived as soon as it's made available for us to use.

OCSP stapling with Must-Staple was the best path forward for working certificate revocation checks but had poor adoption. OCSP responses with signed revocation data for a certificate from the Certificate Authority generally had several days of validity. 6 day validity certificates sidestep all this.

We have 2 special case services which did not use OCSP stapling with Must-Staple and are still using the default Let's Encrypt profile: SUPL and SMTP. Older generations of end-of-life Qualcomm Pixels didn't support SNI for SUPL in the Qualcomm cellular radio TLS stack. Some mail servers still don't.

We can drop this workaround for SUPL once we decide to drop service support for older generation Qualcomm Pixels. Qualcomm did eventually add SNI support for SUPL and it's available on 5th gen Pixels but not 4th gen Pixels. For SMTP, we do require TLS1.2+ but SNI wasn't mandatory until TLSv1.3.

We're in the process deploying a major upgrade to the GrapheneOS server infrastructure to provide faster connections to our services and higher robustness.

If you notice any new issues connecting to our services, please report them in our Infrastructure chat room (https://grapheneos.org/contact#community-chat).

Since August 2021, we've been hosting authoritative DNS for GrapheneOS domains with our own servers. Authoritative DNS is where the mapping from names like releases.grapheneos.org to the IP addresses and other information is provided. DNS resolver servers query authoritative DNS and cache results.

We moved to self-hosting authoritative DNS to deploy GeoDNS for steering traffic to nearby servers combined with health checks to direct traffic to servers which are still up when there's downtime. We investigated various providers but decided to self-host for independence and minor privacy reasons.

In June 2023, we moved ns2.grapheneos.org to 3 servers on BuyVM (New York, Las Vegas and Luxembourg). We use BuyVM's anycast IPv4 support to send IPv4 DNS traffic to the nearest server, which improves latency. It's a very basic anycast feature without IPv6, failover or many locations but works well.

DNS has automatic fallback if an authoritative nameserver is down so our DNS continues working if either OVH or BuyVM is completely down. Our main 3 services (website, network and update servers) are multi-provider with 5 minute DNS Time-To-Live so those keep working if 1 provider goes down.

Our initial setup had ns1.grapheneos.org on an OVH VPS in Beauharnois. BuyVM was used to replace the initial ns2.grapheneos.org on an OVH VPS in Gravelines.

The major upgrade we've started deploying today is replacing ns1.grapheneos.org with a dynamic anycast network for IPv4 and IPv6.

We're using the Rage4 AnycastIP service for the ns1.grapheneos.org IPv4 and IPv6 addresses. This is a more advanced anycast service with 21 locations and dynamic routing to our instances based on us announcing IPs to their nodes with BGP. We've added a server in Frankfurt and will be adding more.

This service allows us to continue hosting authoritative DNS ourselves with multiple providers for redundancy while using our own GeoDNS and failover. We now have anycast for both ns1.grapheneos.org and ns2.grapheneos.org, but it's more advanced for ns1 with IPv6, failover and more location options.

We plan to replace the Beauharnois VPS with New York to have it near a Rage4 New York node. Our new Frankfurt VPS is already right near the Rage4 Frankfurt node. We also plan to add Seattle and Singapore soon. Adding more can be done alongside new website and network server instances in the future.

We also plan to make a small upgrade for ns2.grapheneos.org by adding the optional Miami location via BGP once BuyVM has stock available. BuyVM will hopefully add a Singapore location and IPv6 support in the future, which are the main weaknesses other than lack of failover beyond Miami going to NY.

One of the side benefits of hosting our own authoritative DNS is providing opportunistic DNS-over-TLS (DoT) between resolver servers and our authoritative servers (https://datatracker.ietf.org/doc/rfc9539/). DoT isn't needed for authentication since reasonable servers enforce DNSSEC but it improves privacy.

Several large public resolvers including Google Public DNS and several European ISPs have adopted opportunistic ADoT (Authoritative DNS-over-TLS) and use it with our servers. There's no way to ENFORCE using ADoT yet but we're keeping an eye on it. We have valid WebPKI certs + DANE TLSA for it.

If you're curious about the configurations we use on our servers, most of that is available in these 2 repositories:

https://github.com/GrapheneOS/ns1.grapheneos.orghttps://github.com/GrapheneOS/infrastructure

Our bird.conf for announcing our anycast IPs via BGP to Rage4 and the routing setup script aren't published yet.

We've added OVH instances for ns1.grapheneos.org in Singapore and Hillsboro, Oregon for now. We can consider using Vultr in the future for more locations and closer proximity but metered bandwidth isn't appealing. We could also eventually handle managing anycast ourselves.

If we owned an IPv4 /24 and IPv6 /48, we could announce anycast IPs from Vultr via BGP ourselves. That would mean we'd need to manage optimizing anycast routing which we aren't interested in doing right now, so we'll leave that up to Rage4 for now. We also don't own IP space yet.

You can see the quite decent results we're getting with only 4 VPS instances with 2 in imperfect locations:

https://ping.pe/ns1.grapheneos.org

Here's how that compares to the single server:

https://ping.pe/0.ns1.grapheneos.org

OVH does have many locations via Local Zones but not for what we use.