Met someone who had their coldcard cracked in the first wave, they were late to realise it. A seriously awful situation. My funds are safe as I do not use one, but feels different actually seeing it in the action.

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

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.

VeraCrypt - Free Open source disk encryption with strong security for the Paranoid

VeraCrypt is free open-source disk encryption software for Windows, Mac OS X and Linux. In case an attacker forces you to reveal the password, Vera...

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.

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

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

Android Open Source Project

Rate-limiting | Android Open Source Project

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 Blog

Insider Attack Resistance

Our smart devices, such as mobile phones and tablets, contain a wealth of important personal information that needs to be kept safe. Google is cons...

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:

Features overview | GrapheneOS

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.

Features overview | GrapheneOS

Releases | GrapheneOS

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

#GrapheneOS releases based on Android 17 are in Stable now. Enjoy Android 17! View quoted note →

An Android 17 release of #GrapheneOS is now available in the Alpha channel for users who do not want to use an experimental channel. This is a major release with some more slight UI changes and an introduction of a Desktop Mode that can be enabled by plugging in a device to an external display via USB-C DisplayPort Alt Mode on Pixel 8 and later. We are regularly working on more fixes in the mean time and it is likely a later release will end up in Stable as there are more releases ready to come now.

Today is the official release day for Android 17. We've already fully ported #GrapheneOS to Android 17 and are in the process of pushing the code to our public repositories. We're building a final official release based on Android 16 QPR2 today and we'll do an initial Android 17 release tomorrow. We've already tested the Android 17 port of GrapheneOS on the Pixel 6a, 7, 7a, 8, 10a, 10 and 10 Pro Fold. It will be possible for people to start building and testing it themselves later today once we finish pushing the code. We'll start the process of public testing for official releases tomorrow.

Today is the official release day for Android 17. We've already fully ported #GrapheneOS to Android 17 and are in the process of pushing the code to our public repositories. We're building a final official release based on Android 16 QPR2 today and we'll do an initial Android 17 release tomorrow. We've already tested the Android 17 port of GrapheneOS on the Pixel 6a, 7, 7a, 8, 10a, 10 and 10 Pro Fold. It will be possible for people to start building and testing it themselves later today once we finish pushing the code. We'll start the process of public testing for official releases tomorrow.

June 2026 Android Security Bulletin notes CVE-2025-48595 is being exploited in the wild. It's being widely misreported in tech media as a 0-day vulnerability being exploited. That's a major misunderstanding of Android Security Bulletins and how poorly OEMs keep up with patches. Google disclosed CVE-2025-48595 to OEMs in a security preview release near the end of September 2025. Those patches are allowed to be shipped right away, so it was included in our 2025092501 release. We noted it was already publicly fixed so it was added to our regular releases too in 2025100300. We quickly shipped the patch after it was disclosed to OEMs by Google but we plan to do better in the future. SQLite 3.44.5 was released with this backport on 2025-07-24. We weren't previously aware SQLite maintained upstream LTS branches for Android but our plan is to closely follow those now. In this case, Google slipped up and took 2 months to add the patch to the security preview releases. We plan to avoid that in the future by handling this ourselves because this happens too often. It's also a nice example of how Android Security Bulletins are set extremely low expectations for OEMs. #GrapheneOS quickly ships all security preview patches. Every AOSP patch included in the Android Security Bulletins was already available in GrapheneOS for over a month. We end up shipping patches 2-3 months earlier. Google having such low expectations for OEMs and even themselves is ridiculous. Android's security patch system doesn't make any sense and is completely at odds with how quickly people can discover and exploit vulnerabilities with the help of LLMs. The security preview release system would be far more reasonable if the embargo for sources and details was no more than 48 hours. Google's embargo system harms security for nearly all Android users by setting the expectation of patches taking 2 to 6 months for OEMs to ship after disclosure. Patches are available to sophisticated attackers as soon as Google discloses them to OEMs. A partial embargo for months makes no sense.