#GrapheneOS version 2025092700 released. This release adds official support for using RCS in the Google Messages app if you use Sandboxed Google Play and choose to install it. Using this requires granting the Phone permission to Play services to provide carrier information to it, granting the required permissions to Google Messages and then setting Google Messages as the current carrier messaging app. Setting an app as the carrier messaging app provides it with device identifier access which is documented in our FAQ. However, Google Messages is a special case where part of the implementation is in Play services. We've dealt with this by special casing the device identifier permission check to detect when the user has granted this access to the official Google Messages app which then also provides the official Play services app with the same access. This doesn't provide any extra access in practice since Google Messages shares the information with Play services. Re-enabling RCS after disabling it isn't expected to work yet and you'll need to clear the app data to enable it. • add SystemUI and Settings integration for detecting and notifying Pixel 6a users with batteries impacted by the fire hazard issue resulting in capacity and charging being throttled along with directing users to the support options for getting a free battery replacement, $150 credit or $100 cash as compensation for the faulty battery (a subset of this will be replaced by AOSP code when Android 16 QPR1 is finally pushed to AOSP) • Sandboxed Google Play compatibility layer: add request for the unprivileged READ_PHONE_NUMBERS permission to Play services since it's needed for RCS activation but is not requested since they request the privileged permission instead • Sandboxed Google Play compatibility layer: when users have granted device identifier access to the official Google Messages app by setting it as the default SMS/MMS/RCS app • Vanadium: update to version 141.0.7390.43.0 • Vanadium: update to version 141.0.7390.43.1

Releases | GrapheneOS

Please do not daily driver Kali Linux for home computing. That's not what you use it for Somehow seeing this happen. Don't do it

Latest Vanadium release adds support for WebAssembly even when JavaScript JIT is disabled. - Enable support for the DrumBrake WebAssembly interpreter previously exclusive to Microsoft Edge to support WebAssembly when JIT compilation is disabled. JIT compilation is disabled by default in Vanadium with a per-site toggle to opt into it for improved performance that's rarely needed. Vanadium also blocks dynamic code generation via seccomp-bpf in processes other than the per-site renderer sandboxes for sites where the user has enabled JIT compilation. WebAssembly normally depends on JIT compilation and users previously had to enable the per-site JIT toggle for sites requiring it even if the improved performance of JIT compilation wasn't needed. It should no longer be necessary to enable the per-site JIT toggle for compatibility reasons, only if users want to improve the performance of a demanding web application. Certain optional WebAssembly features aren't yet supported by the DrumBrake interpreter but this shouldn't reduce compatibility in practice since dynamic detection with fallback code is already required for broad compatibility. #GrapheneOS View quoted note →

The first Security Preview release of #GrapheneOS is now live and available to opt in. Android has scheduled monthly security patch releases. For security patches, Google assigns patches to be released in different months in the future, and are then distributes them early to Android OEMs with a source code release embargo that lasts a month. This means that they fix certain vulnerabilities 3-4 months before an official publication date. This is problematic, as this is just a manual delay getting patches to users that can be taken advantage of by highly sophisticated threats. It is September 25th. There are security patches scheduled for December that aren't going to be released until then. By being able to opt-in to a Security Preview you get such patches before everyone. We will still work to make early patching in the main release branch of GrapheneOS as we have done already. These are all brand new changes we have access too thanks to our new OEM partnership. To keep GrapheneOS open source and not delayed open source, this will strictly be opt-in and on a separate release channel. Do not opt in if you do not want that. The Security Preview is for people: - Who want patches immediately, without the traditional 1 month delay. - Who want to perform security research / reverse engineering on the latest Android security patches. View quoted note →

#GrapheneOS version 2025092500 and Security Preview 2025092501 released: This update adds more Android 16 QPR1 backports and the ability to opt-in to Security Preview updates. The Security Preview update channel have very early full patches that are held under an embargo. The first Security Preview will contain extremely early security patches scheduled to be released in Android by December. The security preview provides patches for 55 (1 critical, 54 high) vulnerabilities. Changes added to 2025092500: - System Updater: add support for opting into security preview releases - backport more cellular related code from Android 16 QPR1 - backport Pixel Wi-Fi extension APEX from Android 16 QPR1 - Vanadium: update to version 140.0.7339.207.0 Additional security patches from the November 2025 and December 2025 Android Security Bulletins are included in the 2025092501 security preview release. List of additional fixed CVEs: Critical: CVE-2025-48593 High: CVE-2022-25836, CVE-2022-25837, CVE-2023-40130, CVE-2024-43766, CVE-2025-22420, CVE-2025-22432, CVE-2025-32348, CVE-2025-48525, CVE-2025-48536, CVE-2025-48544, CVE-2025-48555, CVE-2025-48567, CVE-2025-48572, CVE-2025-48573, CVE-2025-48574, CVE-2025-48575, CVE-2025-48576, CVE-2025-48577, CVE-2025-48578, CVE-2025-48579, CVE-2025-48580, CVE-2025-48581, CVE-2025-48582, CVE-2025-48583, CVE-2025-48584, CVE-2025-48585, CVE-2025-48586, CVE-2025-48587, CVE-2025-48589, CVE-2025-48590, CVE-2025-48592, CVE-2025-48594, CVE-2025-48595, CVE-2025-48596, CVE-2025-48597, CVE-2025-48598, CVE-2025-48600, CVE-2025-48601, CVE-2025-48602, CVE-2025-48603, CVE-2025-48604, CVE-2025-48605, CVE-2025-48607, CVE-2025-48609, CVE-2025-48611, CVE-2025-48612, CVE-2025-48614, CVE-2025-48615, CVE-2025-48616, CVE-2025-48617, CVE-2025-48618, CVE-2025-48619, CVE-2025-48620, CVE-2025-48621 We're allowed to provide an early release with these patches and to list the CVEs but must wait until the embargo ends to publish sources or details on the patches. We strongly disagree with broadly distributing patches to OEMs 3-4 months before the official publication date. It further delays getting patches to users and sophisticated attackers will have no issue getting the patches from one of many people at Android OEMs with early access. It should be limited to at most 7 days. The lack of actual secrecy has been acknowledged through Android limiting the embargo to source code and details which allows us to fix these early. We're doing it with separate opt-in releases to keep the regular releases properly open source instead of delayed open source. We plan to integrate this choice into the initial setup wizard. The positive side is that we can now provide patches to people who truly need them without even the previous 1 month embargo delay.

Next release of #GrapheneOS will add support to opt-in for Security Preview releases. These will be separate release channels for users to receive security patches that have source code and vulnerability information under an embargo. The next security preview contains early patches for 1 Critical vulnerability, and 54 High vulnerabilities.

For users of the 'Helium' browser going all over Twitter, it is ungoogled-chromium based, so the following flags are available. They advertised it on their site, but there's no full docs releases by them. Putting here so most can see it. Not an endorsement of a browser, especially one that is so new. People conscious about their security should stick to established apps that they trust. View quoted note →

This ergonomics shit is serious Put the top of your monitor at level to your eyes Avoid bending your neck Keep monitor an arms reach away Ensure shoulders do not shrug when you type Do not bend your wrists Do not lean forwards Keep arms, shoulders, legs straight Ensure feet are touching a surface Use an adjustable padded seat Make sure the height is high enough to sit with your knees further down than your thighs Have the back straight or very slightly leaned backwards Stand up and walk around every 30 minutes View quoted note →

Had to bring this burned npub post back. View quoted note →

Researchers at Trinity College Dublin, lead by Professor Doug Leith did a report to determine if Airplane Mode in #GrapheneOS and other devices actually disabled cellular. It doesnt have any cellular transmissions. https://www.scss.tcd.ie/Doug.Leith/pubs/airplane_mode_report.pdf There is a radio activity spike at the 2.4GHz band, this suggests Wi-Fi activity and is different from cellular network activity. All credit to Doug here: https://www.scss.tcd.ie/Doug.Leith/

The Linux kernel is a gigantic, complex project written pretty much entirely in a memory unsafe language. It is a monolithic kernel with no internal sandboxing/isolation and all the normal code running as part of them is fully privileged. A little typo causing memory corruption can be used to perform dangerous attacks. The Linux kernel alone is focused on performance and compatibility, not security. Even with the countless hardening work and security tools we make for Linux (hardened malloc), Linux is the core security liability in GrapheneOS. If people want the security of the operating system to go beyond, then the Linux kernel must be replaced with something new from the bottom up. Our roadmap page was updated to reflect our approach better. The initial phase for the long-term roadmap of GrapheneOS is to deploy and integrate pKVM and CrosVM. We would securely deploy Android apps in virtualized environments using this virtualization setup. Virtualization will allow us to contain Linux. In the longer term, Linux inside the sandboxes can be replaced with a compatibility layer like gVisor, which would need to be given a new backend alongside the existing KVM backend. Over the longer term, i.e. many years from now, Linux can go away.

Frequently Asked Questions | GrapheneOS

View quoted note →