Earlier today, ARIN fulfilled our request for an IPv4 /22 via their IPv4 Waiting List. We now own the following IP space: 2602:F4D9::/36 23.149.124.0/24 23.149.125.0/24 206.220.120.0/22 Our initial 2x IPv4 /24 were quickly obtained via NRPM 4.10 for our ns1 and ns2 anycast DNS.

Yes, that will be the initial supported phone. Wait for official news about it.

Near the end of May 2026, Russia began filtering access to DataPacket IP space with an enforced domain allowlist for HTTP and TLS SNI. GrapheneOS services aren't on the allowlist so we had to switch from DataPacket Frankfurt to Cherry Servers Amsterdam for Russia. That's now getting filtered too. We've fixed it again by using Zare London for connections from Russia instead. That's the final of our sponsored servers in Europe we can use so we'll need to fall back to Xenyth Toronto if they filter it. We're using our own IP space in Toronto so it should work unless they specifically block us. We don't think we'll be blocked directly but we're also unlikely to get placed on the allowlist. That means our services are gradually going to become inaccessible in Russia via the IP space of major cloud services. Our own IP space will still work fine and we don't host any VPN services ourselves. Our website, OS updates, app repository, connectivity checks, network time, network-based location, geocoding and other main services should work again in Russia. It's likely they'll expand to filtering Zare's IP space and then we'll have to use Toronto where we have our own non-anycast IPv4 /24. They use a domain blocklist for most of the internet and an allowlist for many VPS and dedicated server hosting providers to block access to VPN services. It's likely they'll expand to enforcing an allowlist for every major server hosting provider. That's far more aggressive than China's filtering. Our authoritative DNS is hosted via 2 anycast networks using our own ASN and IP space so it hasn't been impacted by this. It's likely we can avoid it for the rest of our services by using our own IP space. If they start filtering netcup IP space, we can make a reverse proxy to those from Toronto. If our services are blocked, connectivity checks can also be set to Standard rather than Disabled to use the Google servers. That'll keep automatic selection of networks with internet working along with automatic captive portal handling and JobSceduler not assuming every network has internet access.

GrapheneOS has strong defenses against data extraction. It heavily builds upon the standard security features provided by Android 17 and the most secure hardware available for Android. Currently, only Pixels provide the hardware security features and updates required by GrapheneOS. That's going to change in 2027 thanks to our partnership with Motorola Mobility and progress being made by Qualcomm. Disk encryption provides strong protection for data. Even the most sophisticated attackers aren't going to be directly breaking it. They either need to exploit the OS while in After First Unlock state or brute force the PIN/password. Android 16 QPR2 calls for a secure element implementing rate limiting ramping up delays. It's 4 hours after 10 and 41 days after 15. Only 20 attempts are allowed. For usability, It rejects the most recent 5 unique failed attempts early to avoid wasting attempts on repeated errors. GrapheneOS only supports devices implementing the latest generation secure element rate limiting. source.android.com/docs/secu… The secure element on the supported devices also has insider attack resistance. That's implemented by requiring the Owner user to successfully authenticate before the secure element firmware can be updated. A valid signing key and greater version number aren't enough alone. The purpose of this is preventing any government from bypassing the rate limiting by coercing the creation of a firmware update removing the rate limit. Pixels have used a secure element with an internal timer implementing rate limiting and insider attack resistance since the Pixel 2 launched near the end of 2017. Here's a post about this from back in 2018: android-developers.googleblo… The secure element and integration into the OS has become far better since then, but it shows this goes back a long way and isn't a new feature. GrapheneOS also raises the character limit for passwords from 16 to 128. This enables using high entropy diceware passphrases not depending on the secure element rate limiting. To make a strong passphrase convenient to use without ruining it with biometric unlock, GrapheneOS adds an optional 2nd factor fingerprint PIN. We reduce the allowed fingerprint attempts from 20 to 5 and failure to enter the correct 2nd factor PIN counts towards it. This enables using 6-8 random diceware words as the main unlock method required in Before First Unlock and fingerprint+PIN using a short PIN for convenience. Using a valid fingerprint prompts to enter the 2nd factor PIN which is needed to complete unlocking the screen and hardware keystore. GrapheneOS greatly improves the exploit protections for the OS with hardened memory allocators and other features. It heavily uses hardware-based security features including hardware memory tagging (MTE) to protect against exploits. A partial overview of those protections is here: grapheneos.org/features#expl… GrapheneOS adds specialized protection against attacks with physical access too. For example, it blocks new USB connections at a software and hardware level by default while locked and disables USB data as soon as there are no active USB connections. GrapheneOS shipped a locked device auto-reboot timer back in June 2021. It can be set between 10 minutes and 72 hours. We enabled it by default using 72 hours and then lowered it 18 hours. It automatically returns the device to Before First Unlock state due to our memory zeroing as part of tearing down the OS and booting. We got Pixels to add memory zeroing for booting the firmware fastboot mode in April 2024. Apple and Google added a locked device auto-reboot timer in iOS 18.1 and Android 16. For Android, it can be enabled with the Android Advanced Protection Mode. Our implementation is better for multiple reasons but it's a useful feature regardless. Android uses separate encryption keys for each secondary user and Private Space. GrapheneOS adds support for putting both back into Before First Unlock state without a reboot via end session for secondary users or toggles for either to do it by default. It's still much better for the device to be rebooted to get the main user back at rest, completely clear leftover data from RAM and block secure element updates. Our duress PIN/password feature is a minor feature fitting into the bigger picture. It wipes the device when it's entered in any OS prompt for the current profile's PIN or password. It will wipe the device when entered into the authentication prompt for changing a sensitive setting or anything else requiring it, not only the lockscreen. It works across every profile including secondary users and Private Spaces, not only the main user. There are multiple ways to use the duress PIN/password feature including writing it down on a phone case or a paper kept in a wallet. People should carefully consider how to use it in an actual duress situation where there can be physical or legal consequences for wiping the device. GrapheneOS doesn't require it to protect data from being extracted from the device, but it takes recovering it completely off the table even with the PIN/password for each profile on the device. GrapheneOS doesn't depend on the duress PIN/password to protect user data. It's one of the tools it provides among the major privacy and security improvements it offers as a whole. Our features page provides an overview of what GrapheneOS offers compared to standard Android 17. It covers most of the major features we provide and many of the minor ones but there's also a lot more beyond it. Our release notes are a lot more exhaustive since we make sure to cover everything when it's added, changed or removed. grapheneos.org/features grapheneos.org/releases#chan…