#GrapheneOS information on Cellebrite referenced in Amnesty International report "A Digital Prison" about Serbian protest suppression. https://www.amnesty.org/en/documents/EUR70/8813/2024/en/

Android 16 QPR1 is a big deal for #GrapheneOS. All of the major desktop mode features will be available in this version. A lot of it is available as developer options for an early preview on GrapheneOS but will be fully production ready by the time we have A16 QPR1. This will allow a Desktop experience for users. Modern Pixels can then dock their device and use a mouse and keyboard to navigate the UI. A functional desktop mode is huge, but it is a stepping stone towards a far greater feature target for us: A Desktop OS VM manager. One OS feature (the Linux terminal app) already provides a Linux command line using a Debian virtual machine. Ideally, we would want to move away from a non-hardened desktop distribution like Debian, which the upstream uses, and have something an ARM build of secureblue, securecore or even a gold target for Windows 11 ARM for superior app compatibility. Here you can see desktop operating system apps within a freeform window over the standard GrapheneOS applications. There are many unique setups and software choices if we can further develop this: Gaining desktop functionality and including being able to run GUI Windows and desktop Linux applications via hardware accelerated virtualization will then lead to further innovative features, including: 1) Running a specific app or an entire profile via GrapheneOS virtual machines seamlessly integrated into the OS. 2) Running Windows or desktop Linux applications with desktop mode + USB-C DisplayPort alt mode on the Pixel 8 and later. 3) Create an amnesiac virtualized environment nested within the OS user that could be plausibly deniable. There are also a few massive targets that would take a lot of work and wouldn't be seen yet, but worth considering. For example, Android provides Chromium's layer-1 sandbox as an OS feature available to be used by any app via isolatedProcess. It would be fantastic to move this to virtualization using microdroid. It'd be a large project, but have a very high impact for browsers, like per-site virtual machine instances. That would provide security above Tor Browser and comparable to Microsoft Edge's deprecated Application Guard feature that ran Edge in an isolated virtual machine but at a more seamless and useable scale. Since isolatedProcess is an OS API, it'd benefit all Chromium-based browsers and other apps using it rather than being specific to Vanadium. That'd be a difficult project but we can consider it as a future large feature on the same scale as our sandboxed Google Play feature. This would make many apps get a large security boost.

thanx, Must have typed it off on accident when adding the banner and profile pic

Today was the coordinated disclosure date for multiple Matrix chat protocol vulnerabilities: https://matrix.org/blog/2025/08/security-release/ Our #GrapheneOS synapse server has been upgraded to 1.135.2 and now we'll need to upgrade our Matrix chat rooms. Many servers haven't yet upgraded and won't be able to join. Our plan is to create an entirely new set of Matrix rooms with room version 12 and begin migrating people over to those. Our existing rooms will be kept around for a while because we know many instances are going to take their time updating to the new server software releases. Our Matrix chat rooms have been repeatedly broken by these protocol bugs. Our General and Offtopic rooms have been replaced 4-5 times. The most recent occurrence was our GrapheneOS Space with over 25000 users breaking. This will all hopefully be in the past after today's fixes. See https://grapheneos.org/contact#community-chat for more info. Our rooms are bridged across Matrix, Discord, Telegram and IRC. We started on IRC and intended to fully migrate to Matrix. We added Telegram due to the major issues with Matrix and then Discord for ordinary users which is now the most active platform. Federating with open registration Matrix servers leads to endless raids including people spamming CSAM and gore. Not federating makes it quite useless. A large portion of our Matrix community moved to Discord due to the CSAM spam across Matrix and we don't bridge media from it. Discord has very good configurable server-side filtering and dramatically better mod tools. Matrix heavily enables abuse through federation and doesn't even support restricting inline media. Matrix also lacks channels within rooms so communities like ours rely on moderation bots. Discord provides a fantastic user experience and moderation tools but is a closed source platform without end-to-end encryption for direct messages. We would be happiest with an open source, non-federated chat platform we could host ourselves similar to Discord but that time is too late.

#CalyxOS posted an announcement about the departure of both the founder of the organization (Nicolas Merrill) and lead developer of CalyxOS (Chirayu Desai): https://calyxos.org/news/2025/08/01/a-letter-to-our-community/ According to their post, it will likely be around 4 to 6 months before they resume updates with new signing keys. CalyxOS is stuck on the 2025-06-01 patch level. The missing patches include 2 remotely exploitable Exynos cellular radio vulnerabilities fixed for Pixels in June along with many High severity issues for other components. There are a huge number of AOSP patches scheduled for disclosure in September. Android has quarterly major releases. Android 16 QPR1 is coming in September and changes more overall than Android 16. Providing full AOSP patches requires the latest release since only High/Critical severity AOSP patches are backported. It's also needed for the Pixel driver and firmware updates. Verified boot signing keys can't be rotated. Their plan to change all of the signing keys will require reinstalling the OS to continue receiving updates. Nicolas Merrill was the sole person with access to CalyxOS signing keys. Either he isn't handing over the signing keys or they don't trust him. #GrapheneOS was founded as an open source project in 2014. In 2018, there was a takeover attempt on the project by Copperhead which was a for-profit company founded in late 2015. Copperhead was meant to be sponsoring the project and making it sustainable. Both Nick and Chirayu were involved in this. Chirayu Desai was a full time employee of Copperhead. The CEO intended for him to be lead developer of a new closed source OS forked from our project. Nicolas Merrill was in active contact with Copperhead and wanted an OS made for Calyx. When the takeover failed, he hired Chiyaru to make CalyxOS. CalyxOS never incorporated privacy or security features comparable to GrapheneOS. It was always a non-hardened OS far more similar to LineageOS and /e/. Despite being in a different space, Nick and Chirayu worked hard to undermine the continuation of our open source project alongside Copperhead. Calyx should publish information on why Nicolas Merrill was previously demoted and what's happening with the signing keys and other infrastructure he controls. CalyxOS users deserve to know whether he's refusing to hand over keys, domains, IPs, ASN, etc. and if Calyx considers the keys compromised. https://sec.gov/Archives/edgar/data/2009536/000200953624000001/xslFormDX01/primary_doc.xml is the SEC filing for shares issued in February 2024 by a for-profit telecommunications company founded in 2019. The owners of the company are Nicolas Merrill, Louis Rossmann and Steve Gerber. This raises a lot of questions, as does other publicly available information. For CalyxOS users considering moving to GrapheneOS, you should know it's not only much more private and secure but also has broader app compatibility and is very easy to install. https://eylenburg.github.io/android_comparison.htm is a high quality third party comparison. You'll likely be more than happy with it. Many CalyxOS users have been exposed to a lot of inaccurate information about GrapheneOS and fabricated stories about our team. Our team is heavily targeted with harassment. We're open to forgiving and unbanning people who participated in this in the past if they're going to stop and do better.

I don't think I'd be the person to ask. My impression would be you would need to port the entire Android runtime and have all the available APIs for apps, have full support for all of the hardware supported devices use and more. For virtualization a hypervisor would need to be built if an existing solution doesn't work out. There's probably a lot more I'm missing. Exiting Linux is an extremely far future wish and I think the team would prefer these projects to mature first. I'm also not a microkernel developer so there's countless details I think I would likely be missing out... I'd be more interested to see a deliverable high-security daily driver desktop operating system with a microkernel with app sandboxing, permission controls, exploit mitigations etc. Disposable VMs would be something the project would look at when making a VM manager. Running apps in GrapheneOS VMs would be part of that idea.

We haven't been supporting Samsung devices to begin with. They intentionally perma-kill certain features and hardware functionality when you did unlock and install other OSes.

Upstream? Around September

Seeing countless mentions of the project on Twitter because some Ethereum token made a web app that had a similar name to an unmaintained fork of GrapheneOS. Now it is flooded with AI slop accounts promoting this random web app as a GrapheneOS distribution. AI slop is the best!

Ok so we're on 1000 followers again on this npub, thanks!

If our funding and manpower was unlimited, GrapheneOS wouldn't be using the Linux kernel at all, ideally something akin to a microkernel with a hypervisor written in a memory safe language like Rust. We'd then have an Android compatibility layer to run the apps. Android userspace already provides a lot of the safety by apps being developed officially in Kotlin or Java. Linux kernel security flaws make up a lot of Android issues and are what ends up getting exploited in the wild by companies like Cellebrite. The Linux kernel itself is the biggest security liability. Having a more secure base means less hardening work. There was a post I made a couple months ago about Linux kernel (and Android specific) vulnerabilities that Android didn't fix but GrapheneOS had. This type of OS is interesting: https://www.redox-os.org/ These projects need to get contributions and growth, these are the type of operating systems developers should be working on.

Yelling "NOSTR" like I am Kendrick Lamar

The Pixel 8 and later is far more secure than the 7th generation and earlier because ARMv9 hardware security features like hardware memory tagging are available and the OS uses them. It's a huge difference but not something people would see with their own eyes. The 9 is slightly better than the 8 but not in a huge jump like 7 to 8 is.

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.

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

I see this a lot so I will clarify. The major UI theme change, quick tile layout settings and desktop mode are Android 16 QPR1 features. That is in beta and isn't an open release yet. GrapheneOS is based on Android 16 and will move to QPR1 once it is released out of beta.

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.

I tried to give the benefit of the doubt and thought so, but they admitted in the linked GitLab repo that their processor itself didn't support it. >Our machines run older server grade CPUs, that indeed do not support the newer SSE4_1 and SSE3. https://gitlab.com/fdroid/admin/-/issues/593#note_2681207153