In response to recent suggestions mentioning it: > If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism. https://veracrypt.io/en/Wear-Leveling.html The decoy profile concept many have suggested for years is far more flawed than this. It wouldn't hide the presence of other profiles and would be trivially identified. Basic forensic software on a laptop would identify it without exploits. It would also make exploits far easier.

We don't make features designed to trick people with no technical skills because people who were compromised ALWAYS underestimated the capability of the threat that targeted them. You shouldn't rely on slight of hand or pretty tricks, you should just have *more security*. GrapheneOS is becoming far more popular and recognizable so you can't guarantee you will be trusted that your 'decoy' is legitimate to someone. All enforcement agents use widespread commercially available forensic extraction tools. You don't need to be smart to use it. Please Google screenshots of Cellebrite UFED, a child could navigate it, it is that simple. It doesn't need a special device and you can run it on a laptop. It uses ADB to perform extraction and a secondary user does not have access to configure the features. There is zero deniability designed with the user profile approach and that's why it wouldn't be considered with many implementations people make up. Owner also hosts critical OS functions, so it cannot be wiped. It would require a massive redesign on how the OS users and filesystem encryption is laid out. Virtualization is the way to go for something like this.

Because I am seeing discourse on the Elon app about it, see this old reply:

It's trivial to detect an alternate profile without access to developer options and the main ADB shell. It will be detected as part of standard forensic data extraction. Wiping secondary profiles can be easily detected too. Everyone is going to know the feature exists if it's broadly deployed. A deniability feature would need to be set up very differently to what people think it should be like. With GrapheneOS being able to run and use Virtual machines, we'd want to work on a feature where there is a virtualized GrapheneOS in the future where it could be set up like this.

Chromium fork devs: We shall name it *throwing dart at periodic table*... Gallium Firefox fork devs: Introducing the Gooch Browser

Duress makes all data unrecoverable. The entire disk on Android OSes are encrypted and duress instantly wipes the Secure Element and SSD encryption metadata. Data on the Secure Element is one of many parts that derives the credentials to decrypt data. FBE on Android provides separate encryption credentials for profiles, so deleting a profile deletes all data on it permanently. See this article for a detailed overview: https://osservatorionessuno.org/blog/2026/05/demystifying-phone-unlocking-tools-a-technical-overview/

Contrary to popculture and internet trend narratives, the majority of cyber attacks are not sophisticated. Behind some of the worst cyber attacks are what an industry worker would refer to as a common security deficiency. These are flaws that are very common and are regularly discussed. These things could be: - Delayed or no security patching - Missing second factor authentication - A misconfiguration or using a i configuration, whether it be crypto, application settings, etc. - Insufficient or lack of access control - Lack of due diligence or awareness from the victim - Insufficient logging or monitoring - Lack of transit or at-rest encryption Equifax, one of the worst data breaches in modern times, was thanks to them not performing security patching on Apache Struts which allowed a threat actor to exploit a known vulnerability. GTA 6 was leaked from a staff member being socially engineered. Snowden perhaps could not have done his whistleblowing if the NSA has stricter access control. The best threat actors use the easiest way in to get what they want. The big letter agencies do not jump through hoops and set up big conspiracies rather they exploit software the same way a professional researcher would try to. This also makes an operation far less attributable, because a common security deficiency could be exploited by anybody. When you regularly see coverage about North Korea ('Lazarus') compromising cryptocurrency companies or users, they are often exploiting these same easily explained weaknesses. If something is too secure, many will easily decide to find a victim that is easier to compromise. What makes them so dangerous isn't their technical capabilities rather than they have far more time and resources because they are state sponsored. They will *never* be held accountable. When you cover all of these deficiencies and more, your tech is probably more secure than 99.9% of people. Now you go from being a victim of a common attack, to something that would need to be bespoke and targeted. When working on security or privacy focused software, think long and hard about the quality of the implementation of your functions. You could have many features, but they may not be helpful if their implementation is poor. A poor implementation of a feature may introduce weaknesses compared to not having the feature introduced at all. Less can truly be more.

#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. https://source.android.com/docs/security/features/authentication/rate-limiting 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: https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html 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: https://grapheneos.org/features#exploit-protection 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. https://grapheneos.org/features https://grapheneos.org/releases#changelog

Really sad to see this is caused by a common security deficiency, either a missing or incorrect configuration. Sensitive crypto operations should not be allowing a fail open.

GrapheneOS does not create identifiers for users nor track them. All services we do host require the minimum for that service to function, for example when requesting an OS update we would only be able to see an IP address checking an update for a certain phone model. Android has an "Advertising ID" but this is Play Services dependent and can be deleted in their settings.

People 'verify' source code far less than people actually believe. The audience of people who actually can are less than people think too. The entropy code was likely read by many people, many times. It means most did not actually understand what was written. Larger projects pay for AppSec teams to do assurance testing / 'audits' because just having visible source code isn't equal to an audit. Suspected and known malware get a more documented, deep analysis by security firms compared to most open source projects.

New #GrapheneOS PDF viewer update with swipe gestures for pages and also a full migration to Kotlin.

An HDD, they don't have wear levelling. Some SSDs may disable wear levelling at the significant cost of drive lifespan.

Exploiting the OS becomes drastically easier after being granted access to a profile. USB becomes available, every radio can be turned on and an app can be installed with every permission granted. Developer options and ADB would need to be available to pretend to be Owner... Forensic extraction software without exploits for locked device is common and not closely guarded. Users these tools only need to follow simple on-screen instructions. Developers of the tools are aware of alternative operating systems. GrapheneOS features have to work when known. Cellebrite and other forensic data extraction companies included information on GrapheneOS in their documentation years ago. That includes it being covered in Cellebrite's tables documenting available capabilities: https://androidauthority.com/cellebrite-leak-google-pixel-grapheneos-security-3611794/ The more recent tables are similar. training.magnetforensics.com/w/courses/15-gk200-graykey-examinations > An awareness module focused on anti-forensic operating systems and applications, with particular attention to GrapheneOS — its privacy and security features, supported devices, data-wipe behaviors, and the handling and seizure considerations these devices introduce. reddit.com/r/embeddedlinux/comments/1josb0i/embedded_linux_jobs_monthly_thread_april_2025/ml3schx/ > Company: Magnet Forensics > > [...] experience in both embedded Linux, and also FPGA gateware. Deep understanding of the USB protocol and stack is a major differentiator - experience here sets you apart [...] > > Technologies: [...] #GrapheneOS, [...] We make privacy and security tech. Privacy and security involve defending against adversaries actively adapting and improving. Companies developing offensive security tech including remote exploits and data extraction tools are aware of GrapheneOS. It's made with that in mind.