GrapheneOS

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

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

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.

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.

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.

In the market for a new phone and I want to try out GrapheneOS. I know I need a Pixel phone (rather ironic i need to get a google device to degoogle), but I already made the mistake of buying a carrier locked pixel previously. If I do buy a phone third party (through google or some other place) and then install GOS on it, would I be able to transfer my services over to the new phone running GOS? Would there be any issues with my carrier?

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 need an Android OEM or someone working at one to provide us with early access to the Android 16 sources in order to have a smooth port this year. We need this before June. We requested it to help with this very difficult situation (see the linked thread) and still need it.

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

GrapheneOS Foundation can sign an NDA for this. We can act as a contractor for an Android OEM or one of their contractors. We need this early access so that we can start early due to the developer who usually does most of it being unavailable. If you can get us this, please help.

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.

Tags:

• 2025050300 (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 2025042500 release:

• extend security state manager service to support the official Auditor release (based on the signing key) obtaining additional security state (currently the configuration for auto-reboot, USB-C port and pogo pins control, OEM unlocking and user count)
• Auditor: add default enabled data saver exemption
• kernel (Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): switch to synchronous mode for the Hardware Tag-Based KASAN implementation to improve security and error reporting (we'll continue using asymmetric mode in userspace where it provides very comparable security and error reporting to synchronous mode with lower overhead)
• kernel (6.1): update to latest GKI LTS branch revision
• kernel (6.1): revert upstream Linux kernel change attempting to work around frame drops caused by a workaround used by video players on X11-based platforms (irrelevant to Android) due to it breaking DisplayPort alternate mode audio
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.88
• PDF Viewer: update to version 29
• PDF Viewer: update to version 30
• Vanadium: update to version 136.0.7103.60.0
• GmsCompatConfig: update to version 157
• GmsCompatConfig: update to version 158

Notable changes in version 89:

• remove support for checking OEM unlocking state outside GrapheneOS since Android 15 QPR2 removed the system property
• add support for GrapheneOS security state manager extension included in the upcoming release of GrapheneOS providing support obtaining additional security state information including the OEM unlocking state, user count, GrapheneOS auto-reboot configuration and GrapheneOS USB-C port and pogo pins control configuration (this requires a signature permission based on the GrapheneOS signing key for Auditor)
• raise minimum API level to 33 (Android 13) since Android 13 is the oldest release with security support
• raise minimum OS version for verification to Android 13
• raise minimum patch level for verification to 2022-08-05 (first release of Android 13)
• drop support for devices without official Android 13 support including 3rd generation Pixels and all previously supported non-Pixel devices (non-Pixel devices running the stock OS will be supported via a generic approach in a future release)
• drop obsolete first API level check for sample submission (no longer relevant due to Android 8 being launch such a long time ago)
• update Guava library to 33.4.8
• update Android Gradle plugin to 8.9.2

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

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Trusted Execution Environment (TEE) or Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

GrapheneOS users must obtain GrapheneOS app updates through our App Store since verified boot metadata is required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Changes in version 158:

• expand Bluetooth stubs to all variants of registerCallback and unregisterCallback

A full list of changes from the previous release (version 157) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

Changes in version 157:

• add stub for BluetoothLeBroadcast.registerCallback()
• update Android Gradle plugin to 8.9.2

A full list of changes from the previous release (version 156) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

Notable changes in version 30:

• make text selection color opaque to resolve recent contrast regression
• update Android Gradle plugin to 8.9.2
• update npm dependencies

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

Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to the network, files, content providers or any other data.

Content-Security-Policy is used to enforce that the JavaScript and styling properties within the WebView are entirely static content from the APK assets along with blocking custom fonts since pdf.js handles rendering those itself.

It reuses the hardened Chromium rendering stack while only exposing a tiny subset of the attack surface compared to actual web content. The PDF rendering code itself is memory safe with dynamic code evaluation disabled, and even if an attacker did gain code execution by exploiting the underlying web rendering engine, they're within the Chromium renderer sandbox with less access than it would have within the browser.

This app is available through the Play Store with the app.grapheneos.pdfviewer.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.grapheneos.pdfviewer id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

GrapheneOS users must obtain GrapheneOS app updates through our App Store since verified boot metadata is required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Changes in version 136.0.7103.60.0:

• update to Chromium 136.0.7103.60
• disable tab group sync feature by default
• raise minimum API level to 33 (Android 13) from 29 (Android 10)
• only enable secondary arch support for arm64 to greatly speed up x86_64 builds for the emulator and slightly reduce their size (will be possible to make the same change for arm64 in the future)

A full list of changes from the previous release (version 136.0.7103.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.

Notable changes in version 29:

• update CSS for recent pdf.js versions to fix major issues with text selection
• update pdf.js to 5.2.133
• automate obtaining the latest character maps, ICC profiles, standard fonts and WebAssembly files from the currently used pdf.js release instead of manually handling updates
• update esbuild to 0.25.3

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

Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to the network, files, content providers or any other data.

Content-Security-Policy is used to enforce that the JavaScript and styling properties within the WebView are entirely static content from the APK assets along with blocking custom fonts since pdf.js handles rendering those itself.

It reuses the hardened Chromium rendering stack while only exposing a tiny subset of the attack surface compared to actual web content. The PDF rendering code itself is memory safe with dynamic code evaluation disabled, and even if an attacker did gain code execution by exploiting the underlying web rendering engine, they're within the Chromium renderer sandbox with less access than it would have within the browser.

This app is available through the Play Store with the app.grapheneos.pdfviewer.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.grapheneos.pdfviewer id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

GrapheneOS users must obtain GrapheneOS app updates through our App Store since verified boot metadata is required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

This is an announcement for people using our Matrix chat rooms through apps supporting Spaces such as Element.

Our GrapheneOS Community Space grouping our chat rooms was broken by Matrix protocol bugs. You should join https://matrix.to/#/#community:grapheneos.org and leave the one without our logo.

Matrix bugs have broken our main General room 4 times and our Off Topic room 3 times. Our Discord server (https://discord.com/invite/grapheneos) was created after the last time our General room was bricked. We also set limits on which Matrix features we use and how we use them to avoid this.

Our current General and Off Topic rooms were created and managed within these limits and haven't broken yet. Our Matrix Space significantly predates the limits we set to avoid bricked rooms and had over 25k users. We expect each room predating our limits will eventually break.

To avoid bricked rooms, we now create all public rooms with @admin:grapheneos.org, never add another admin account, restrict settings/permissions changes to the admin account, only have mods on grapheneos.org / matrix.org and NEVER set invite-only.

Ideally, we'd only have mods on grapheneos.org since matrix.org is the source of many state issues. However, spammed messages often cause lag result in messages not being federated to our server, especially from there. We may limit using it to clean up spam.

"A regression causing fwupd to interfere with using fastboot with all Pixel devices including blocking installation part of the way through has been fixed by the same contributor who fixed the previous issue:

https://github.com/fwupd/fwupd/commit/4650003e3da75c66470eb73c3727e57701682084

It hopefully won't regress again after this.

It isn't part of a stable release yet and it's likely releases with the regressions will be included in frozen distributions for years, similarly to the previous issues. We'll need to tell people to stop the fwupd service for years to come even if it's the last fastboot breakage.

There was a fwupd fastboot configuration using the Google vendor ID and Pixel fastboot product ID used for one of their tests. It caused fwupd to always try to connect to these devices when detected including after reboots during the process of installing firmware and OS images.

Fastboot mainly exists for the purpose of unlocking a device, installing new firmware/OS images, flashing a verified boot key and locking the device. Fastboot isn't an the update sideload protocol, isn't a safe way to do that and isn't used for updates by any reasonable device.

There are very strange cellular radio chips designed for use with Windows including both an actual cellular baseband running typical baseband firmware and a CPU next to it running a proprietary fork of an ancient Android version. They do this to use Android drivers for Windows.

These chips don't implement Android's A/B update system, verified boot, etc. and don't provide proper security patches for the standard baseband firmware or their proprietary Android fork. They're using a protocol for installing an OS as a super unsafe way to do firmware updates.

These radios are mostly connected via USB, which provides far worse isolation and far more attack surface than a typical cellular radio. These were clearly built for Windows to avoid porting drivers/services built for the Linux kernel to it. Pinephones use a variant for cellular.

That's why fwupd implements fastboot. It was initially connecting to every fastboot device and never closing them, preventing using them for anything else. That was fixed, but it continued connecting and breaking installs after reboots. That was fixed, then undone for Pixels.

We filed an issue about this with fwupd in November 2023. The lead developer didn't view it as a bug so we explained what we did here. We explained this is dangerous and people's phones were being at least soft bricked by it. They responded with hostility and attacks on us.

We later learned that the fwupd developer supports Techlore and their project members including their attacks on the GrapheneOS project. Techlore is the origin of most of the harassment directed towards our team based on fabrications they published and pushed in their community.

Techlore's community engaged in years of extreme raids on our chat rooms and harassment towards our developers as they encouraged it. It escalated to their community attempting to kill one of our developers with severe swatting attacks. Techlore doubled down on it following that.

The issue we filed is https://github.com/fwupd/fwupd/issues/6437. Despite the lead developer not acknowledging it as a problem, it was fixed via https://github.com/fwupd/fwupd/commit/cbc4821d8198ec79418a848525d74f24903cbce9. It only got fixed because there was someone else to do it. The problem was then reintroduced a year later but only for Pixels." - As posted by the Official GrapheneOS Account.

Tags:

• 2025042500 (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 2025041100 release:

• Bluetooth: backport upstream fixes for compatibility with certain Bluetooth peripherals caused by a recent security fix for Bluetooth encryption
• avoid granting special runtime permissions (Network, Sensors) added by GrapheneOS when unarchiving an app
• use our restricted setting infrastructure to restrict system app access to our notification forwarding setting too
• Settings: prevent disabling system Dialer app since it's always required for emergency calls
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.134
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.87
• Vanadium: update to version 135.0.7049.100.0
• Vanadium: update to version 135.0.7049.111.0
• Vanadium: update to version 136.0.7103.44.0

ReliableSite has provided two sponsored servers to replace our North American update servers. One is in Los Angeles and the other In Miami. Each has a 9900X, 196GB RAM, 2x 4TB NVMe and 10Gbps bandwidth. We greatly appreciate the support.

https://www.reliablesite.net/

We've already set up both servers, tested them and deployed them to production by adding them to our GeoDNS configuration:

https://github.com/GrapheneOS/ns1.grapheneos.org/compare/d78f0f087446789628927f36bb66268d4bc9cb16...d09a8917742e0c262344ccecfca46b6bb15e1ff1

This was based on our split between Las Vegas and Beauharnois (Quebec) for our website and network servers and may be adjusted.

We were previously provided with a 25Gbps server in Amsterdam by Macarne. These 3 servers now handle all of the traffic for OS and app updates along with fresh installs. It would help to have servers from providers with great peering in a few more places.

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

We should have enough bandwidth for at least the next year or two now. It would still help to have a 10G update server with good peering in Asia and it would be nice having one around New York too. We don't need more bandwidth yet but people's download speeds could be improved.

We also have a bunch of services not consuming much bandwidth compared to updates where we need unmetered VPS or dedicated server instances in Asia. We also need a better way to do anycast for our self-hosted DNS servers. Our ns2 is currently BuyVM anycast which is missing Asia.

Changes in version 136.0.7103.44.0:

• update to Chromium 136.0.7103.44

A full list of changes from the previous release (version 135.0.7049.111.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.