GrapheneOS version 2025061000 released.

Releases | GrapheneOS

See the linked release notes for a summary of the improvements over the previous release. #GrapheneOS

A while ago, a forensics company suggested in the open they are able to overcome iOS automatic reboot timer indefinitely with a unique preservation tool. Automatic reboots force data to return to an encrypted at rest state until they are unlocked again, which mandates the threat actor having to brute force the device for decrypting sensitive data to access rather than bypassing the lock mechanism for an AFU device. Magnet Forensics (GrayKey) are a business leader in iOS forensic extractions and originally began only exploiting on iOS, although supporting other devices now, they are limited in support roster compared to Cellebrite who support a wide range of legacy devices with huge funding and business location that conscripts young technologists into hackers and engineers. GrayKey's founders contain former Apple security engineers. This preserve tool is bundled with their Advanced and Premier plans. Availability of such tools further demonstrates a need for a shorter default time than 72 hours, or a user-configurable option, just like what you can get in #GrapheneOS. Apple needs to put further work in protecting against physical attacks, even if they aren't able to know the tactics used to perform it, additional hardening could close out unknown vulnerabilities, disrupt actors and their progress by defense in depth. https://www.magnetforensics.com/blog/the-importance-of-preservation-for-ios-devices/ https://www.magnetforensics.com/resources/preserving-your-ios-extractions-with-magnet-graykey-and-graykey-preserve/

Discussed this in a SimpleX chat yesterday, but worth thinking leaving thoughts here: A software project that has received a fancy, formal security / privacy audit document shouldn't be considered a gold standard of trust alone. It is a practice that should build a larger image of trust. There's a lot that goes into an application being trustworthy or not. A PDF file from a team / field expert saying a program is good can only go so far. Just because a project may not have a document like this, doesn't mean they are not held under heavy scrutiny or that they do not have trust. It isn't always possible, not may it be fitting to review certain software in such a manner. In fact audited projects may be less scrutinised. A project can be audited but miss out on having potential important security / privacy features. Would you rather use a wallet that was alike to Bitcoin Core that had such a PDF you could read, or would you use a wallet like Samourai (forks) or Wasabi that didn't, knowing it had privacy features? Audits need to be continuous to be most effective. Software that is rapidly updating, adding new features, or ends up changing the architecture significantly are not a good fit for one-time audits. The document would just be an advertising gimmick and nothing more, since it either covers code doesnt exist now, or doesn't cover code that exists now. Security reviews shouldn't be a one time. A far better merit is an application being targeted by security researchers frequently, and vulnerability disclosures are a good sign of scrutinised, improving software. For something like GrapheneOS or a Linux distribution, these things don't work due to the sheer size of the projects and different conditions of users. Security researchers should routinely attempt to uncover vulnerabilities and developers should be campaigned to shift left. These formal reviews do work better for single user facing software projects, or for online services to prove technical claims about their services. But it doesn't mean that it would always be the same since the latest being published though.

#GrapheneOS: 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: Default Default public and private interfaces Default public interface only Disable non-proxied UDP For Vanadium, "Disabled non-proxied UDP" is the default. The tracking technique described at

Ars Technica

Meta and Yandex are de-anonymizing Android users’ web browsing identifiers

Abuse allows Meta and Yandex to attach persistent identifiers to detailed browsing histories.

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

Features overview | GrapheneOS

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.

#GrapheneOS version 2025060200 released. Android 16 is not released yet. 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. 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) 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)

Releases | GrapheneOS

Users of #Obtainium may be interested in this web site:

Open Source Apps APK for Android - OpenAPK

Download free open-source apps in APK format for Android, safe, ads-free and privacy friendly. Sourced from Github, Gitlab and beyond.

It appears to have "Add to Obtainium" buttons to add the source of the app for you. Good for searching known apps. Can be saved as a PWA. Obtainium maintainers also keep a list of app configs for more complex apps at

Complex Obtainium Apps

Crowdsourced "Hard to Add" App Configurations for Obtainium.

A better last resort option should app stores not be sufficient.

#GrapheneOS version 2025060100 released. This release patches out an Android / Linux kernel vulnerability that isn't fixed upstream whose effectiveness was already very limited in GrapheneOS since 2022. 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:

GitHub

unicode: Don't special case ignorable code points · torvalds/linux@5c26d2f

We don't need to handle them separately. Instead, just let them decompose/casefold to themselves. Signed-off-by: Gabriel Krisman Bertazi <krisman@...

Revert:

GitHub

Revert "unicode: Don't special case ignorable code points" · torvalds/linux@231825b

This reverts commit 5c26d2f1d3f5e4be3e196526bead29ecb139cf91. It turns out that we can&#39;t do this, because while the old behavior of ignoring i...

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. Upstream Android 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. 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

Releases | GrapheneOS

#GrapheneOS version 2025051900 released. This update adds support for private spaces in secondary user profiles and the ability to install available apps to private spaces. • 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, similar to the toggle 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 keyboard 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

Releases | GrapheneOS

Next #GrapheneOS update adds support for private spaces in secondary user profiles and the "Install available apps" feature for private spaces and much more.

A cold, hard truth a lot of social media influencer privacy / security enthusiasts won't like to admit about themselves is that you are likely to know much less than you think you actually do. Including myself. A cyber security professional who uses all the normie-tier, status quo products will be far more safe than someone who isn't a professional and is using software focused on privacy or security. If you want to know more you need to study with the mentality like you want to be a professional. The former groups of people know and understand the products they use and their security properties. Depending on the role they also know how to reverse engineer, discover vulnerabilities and have a consistent threat model when building defences. The latter are often using a product because some place online told them to without much critical care or observation. It shows a lack adaptive technical skills, approach or mindset. Talented hackers and security professionals using Windows, Apple products and more aren't hiding some secret incompetence. They just know what their requirements and demands are and their choices fill them. They know they can move and use something tougher at any time should their needs change. Changing a software or a device choice is only a small part. It's a shame that a lot of online spaces have this mentality that many things are completely compromised in secret, when in reality this only works in a nonsensical dystopia where all the intelligent people ONLY work with their perceived threat (whether it is secretive agencies, governments, some advanced actor or whatever else) and the common man is stupid. This is the same mentality that some, like flat earthers, believe how the world is run. Being a hacker is all about learning how things work, how do you think people get to understand malware without source code? How do the bad guys break into systems they never touched? Reading can only do so little in a specialty that changes frequently and information is outdated all the time. A book or and not every forum post can't get updated. If you want to start getting serious, log off the forums and go on a security lab platform and check out their guided training, or take a course, or get a entry level job.