Once Linux VM terminal and support is improved in upstream it could be useful to allow virtual machines that run other OSes other than Debian within GrapheneOS. Fedora is our target. Secureblue could also work if it ever gets built on ARM.

Has a horrible choice of base OS for security and they don't do any significant work to improve it. They do not do any significant hardening beyond application changes and trivial configurations you can do in other distros. A lot of the efforts for Linux kernel hardening on both Whonix and Kicksecure were halted and then undone when the developer responsible for most of it left the project, therefore, it got worse over the years... Their developer also pushed misinformation about allocator hardening and dropped using hardened_malloc (hardened memory allocator used and created by GrapheneOS, a significant exploit protection). Their recommendations appear more out of software freedom movement dogmas than a security researcher perspective. Some tables on the wiki make comparisons seemingly out of imaginary scenarios or remove context to what they source. The Whonix distribution routing everything to Tor has a valid point, but you're just using a non-hardened Debian OS routed through Tor. Qubes users are very reliant on the hypervisor to protect them when using it. The security of the operating systems in the VMs also matter. Making an equivalent out of a distro like an immutable Fedora distribution or Arch would outclass it very quickly. There are projects that do a lot of great effort to start, like Secureblue: https://secureblue.dev/features It inherits a better base OS, has some components from GrapheneOS, including hardened malloc and a desktop Chromium based browser with a Vanadium patch set. Not comparable to the Linux kernel in GrapheneOS (and Android) which is extensively hardened. Since Qubes' standard images are Fedora based, it could compliment it by being a template. Qubes developers already have that in their issue tracker.

We are hesitating to release any handed material to protect sources.

We have the latest documentation from Cellebrite Premium in June 2025 and there are no changes to their #GrapheneOS support. Brute forcing remains unsupported for Pixel 6 and later. We can see if there's anything documented about it in the next Cellebrite Premium update for the stock Pixel OS based on the launch of Android 16 and the opt-in Advanced Protection enabling a weaker USB protection than ours while locked. Despite being weaker, we'd expect it still defeats their current exploits not targeting the lower level attack surface but rather only drivers.

Back to the post, Debian is also an awful Linux distro to choose. Full of anti-security practices.

Users shouldn't fall under pressure to use certain software. In fact, using software just because you was told to, or a crowd recommends it can sometimes come across as incompetence. Understand what you're using. I see a lot of people saying that if you do not use certain software (including GrapheneOS on these lists, then you do not fight for freedom or you are just a roleplayer. I guess I am a roleplayer who doesn't fight for freedom either, because I probably don't use anything else they're recommending me.

Tavi (DivestOS developer) on Fairphone devices (FP3 and FP4) using end-of-life Linux kernels. https://forum.fairphone.com/t/is-fairphone-really-interested-in-sustainability/99302/2

Vanadium is Chromium based but with a lot of security and privacy changes. Because Vanadium is also the OS WebView you can run apps using WebView in a safer fashion, they benefit from such features: https://grapheneos.org/features#vanadium Also a control for WebView JIT per app to reduce a large JS JIT attack surface for them. Our PDF viewer is an example of a WebView app.

ANDROID 16 BUILDS OF #GrapheneOS ARE NOW IN STABLE! https://grapheneos.org/releases#2025070800

Keychat uses the OS WebView for it's browser. The Android OS webview is Chromium based. https://github.com/keychat-io/keychat-app/blob/main/packages/app/lib/page/browser/WebviewTab.dart

Robert Braxman has published another video spreading blatant misinformation about #GrapheneOS in order to promote his highly i products and services. In addition to many false technical claims and fabrications about our team, he's falsely claiming the project is dying. We have a thread already debunking this recent line of attack on GrapheneOS at: https://xcancel.com/GrapheneOS/status/1936420921931084075 GrapheneOS quickly provided the June security patches, was ported to Android 16 and is working with a major Android OEM. It's not dying and we haven't said or implied it is. Braxman presents himself as a privacy and security expert but isn't one. He's a shady businessman selling unsafe snake oil products and services. His content is filled with outright fabrications and is heavily aimed at promoting his products. It misinforms rather than educating.

Not like you can consider "FOX NEWS" a tech journalism outlet. Maybe they should stick to complaining about the culture war on TV or something.

Gemini Nano AI models are designed to be run entirely offline. The AI models do not send telemetry, rather, it's the applications you interface it with that do. The stock OS sends telemetry about it's AI usage, mainly your conversations with the Gemini chat bot. Google admits they keep up to 72 hours regardless of the settings for what they like to call safety purposes. They provide in depth documentation of their telemetry here: https://support.google.com/gemini/answer/13594961 You can use Gemma models on Google's AI Edge Gallery app (open source) and chat with them. In fact, if you disable the network access, it still works. Only needed if you wish to download some (but not all) models from within the app but then can be disabled immediately after. Doesn't need play services. I don't have a Hugging Face account to download Gemma but here is a different model running offline on the AI Edge Gallery to demonstrate:

Because of who is proliferating these talking points and how quickly several news sites in different languages picked it up, we are considering that GrapheneOS is currently under a state sponsored attack by Spanish state employees attempting to deliberately misrepresent it as being for criminals, which we covered a bit here. This has directly led to massively escalated raids and threats on our chat rooms whether or not they're directly doing it or not. These poorly researched, biased and inaccurate news stories are designed to support targeted harassment towards our community for using GrapheneOS and our team by putting pressure and maliciously associating us with bad actors.

We are very disappointed that Android Authority, of all websites, would choose to publish an article like this too. Not only does it frame GrapheneOS in a way that makes it appear harmful, It is full of technical inaccuracies. We have contacted them about this matter. https://www.androidauthority.com/google-pixel-organized-crime-preferred-phone-3573578/

Airplane Mode disables cellular radio transmit and receive, when it is on, they are off. You can still turn WiFi, Bluetooth, NFC etc. while it is on, so any implications for that exist - but the user obviously is aware of them by turning it on. This option would also have nothing to do with operating systems or applications invading your privacy, so don't use such apps. If people can rule up over a video that is just a voice behind AI generated stock footage with CapCut TikTok captions and "scary" music, I can't really help. This content is designed for people who wish to hear things they WANT to hear and believe.

Are you running Android 16 yet anon?

#GrapheneOS based on Android 16 has been through extensive public Alpha/Beta testing and should reach our Stable channel today. We'll continue fixing various upstream Android 16 regressions such as the back button issue impacting the stock Pixel OS we fixed in our latest release. July Android Security Bulletin will likely be published today. We obtained early access to the signed partner preview and confirmed no additional patches were required, so we set the 2025-07-01 patch level last month after we backported Pixel 2025-06-05 driver/firmware patches. Tomorrow will likely be the first monthly update of Android 16 with a new Android Open Source Project and Pixel stock OS release. We won't need to backport Pixel driver/firmware patches since we're on Android 16 and can simply incorporate and ship the monthly update within hours.