Worth noting, we have early access to upstream security patches ready for December. We also can get the early access to Android 16 QPR1 since it isn't in AOSP, but by the time we do this we'd probably have access to 16 QPR2. QPR1 comes in coming weeks. The issue is that the code is embargoed until released to AOSP. Only binaries can be released. We are looking at potentially making a separate binary-only stream of GrapheneOS with these early releases and features, but the audience here likely won't find it interesting since it isn't open source. It's purpose would be for reverse engineering purposes so devs can reverse engineer, make patches and other code from decompiling builds. I would assume most users wouldn't be using this version as their main operating system. View quoted note →

Regarding the recent situation with Proton Mail, I have nothing to comment that I haven't said countless times already. I would need to understand more context about what the users they suspended did, which is in the clouds of social media conflict right now. It is abnormal to suspend a researcher, so I personally would like to see a more formal response from Proton on their justifications -- especially since accounts were reinstated after the matter went public. In the meantime, let us go through a refresher your need-to-know on encrypted email providers. If you are aware already on how Proton Mail works technically and as a business, it should be of no surprise to know the following: - Email is not end-to-end encrypted. Proton Mail encrypts received emails from external domains when they arrive unencrypted. The only encryption is in the transit between the two email providers, NOT the individual users. In theory, a service provider could be legally compelled to intercept email traffic and keep the readable copy as they arrive. Only Proton to Proton emails are end-to-end encrypted. - "Zero-access encryption" is NOT "end-to-end encryption". - Providers suspend accounts on their own due diligence. Should be no surprise companies suspend accounts from reporting from sources like CERTs, ISACs, anti-spam registries etc. If an email provider can't read the mailbox, then this or email contents being reported is the most information they get. Don't act shocked when they aren't on your side. - Don't think irrationally: Removal of service is not at all related to information disclosure. Certain information you provide to the service cannot be encrypted in a way that is unreadable to the service, for example, email account recovery information. It wouldn't be possible to restore accounts using information they don't know. Understand what information you provide to a service provider. Overall: Don't use email for personal highly sensitive communications you believe could be disrupted by a service provider. If there is no way around this, encrypt the email contents and attachments yourself and leave a generic non-sensitive subject line so neither providers can read it. The same applies to self-hosting your own email. Use end-to-end encrypted messaging apps for communication. Keep emails for accounts. Mail providers with mailbox encryption like Proton and Tuta provide encryption as a protection mechanism against data breaches. Using such services are a reasonable choice for someone who needs an email provider with a focus on account security and requiring only the minimum amount of information required to function. But, they are not an opsec silver bullet.

#GrapheneOS version 2025091000 released. This release provides the entire October 2025 security patches EARLY. We are also packing Android 16 QPR1 backports as we wait for AOSP releases. We are also fixing a vulnerability the Linux kernel refuses to fix. • full 2025-10-01 security patch level • partially backport Android 16 QPR1 Pixel userspace device support: RIL, eSIM, TPU and NeuralNetworks (deprecated) • kernel (6.1): roll back recent upstream Android GKI dma-buf changes due to a few MTE crash reports • kernel (6.1, 6.6, 6.12): disable unused memory hotplug support • kernel (6.1, 6.6, 6.12): fix linear region randomization by dropping memory hotplug support (see the Project Zero issue where the upstream Linux maintainers decided not to fix the issue) • kernel (6.1): update to latest GKI LTS branch revision • kernel (6.6): update to latest GKI LTS branch revision • kernel (6.12): update to latest GKI LTS branch revision including update to 6.12.45 • Vanadium: update to version 140.0.7339.123.0 Information on vulnerability:

Project Zero

Releases | GrapheneOS

For #GrapheneOS users concerned on a full Android 16 QPR1 release. Android Authority has reported the source code for Android 16 QPR1 in AOSP will be released 'In the coming weeks':

Android Authority

Android 16 QPR1’s source code is nowhere to be found, but Google swears it’s coming

Google has yet to release the source code for Android 16 QPR1, sparking fears about the company's commitment to AOSP.

This delay is unprecedented. This information matches our own sources and communications. The general consensus is it SHOULD be released, but for some reason it hasn't been.