I don't use Linux on the desktop. Fedora is the least bad choice but having better defaults and try Secureblue if you want it a hardened. Arch also works and certain hardening is available there but not as a default.
Arch Linux also provides proper security updates for the most part through updating to the current stable releases of software. But it is just a standard Linux distribution otherwise and is certainly not hardened.
https://secureblue.dev/ was discussed elsewhere in these comments too.
Debian freezes packages and only updates them during major OS upgrades or when a security fix has received a CVE. This means that if you use software that had a security issue that was fixed and not reported, it's certain you're vulnerable.
There were cases where we were aware of serious vulnerabilities that were fixed in software we used, for example our web server nginx but they did not get the fix in Debian because of no CVE assignment. We don't use Debian on any of our infrastructure. The assumption that every project obtains CVE assignments for each vulnerability is unrealistic.
You can also say the same thing about web browsers, which are dangerous to leave unlatched because they're some of the most widely desired software categories to exploit. Certain Debian users were hit with attack campaigns years ago because of their unpatched browsers.
Freezing updates for applications is anti-security, keeping apps up to date and patched is an extremely basic first security practice.
To answer your question, Fedora is better than most due to not having this package update problem and other problematic Debian quirks like their problematic app configuration and patch choices. All the Linux distributions lack in the OS and app security department and the Linux kernel itself is not immune to critique.
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.
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.
Im an unworthy Fraud when it comes to Tech
submitted by https://lemmy.zip/u/WaffleWarrior
In know what you guys are thinking. “But you are posting in the Fediverse on a phone with GrapheneOS flashed via the command line in a Debian based distro!”
I know I know! But truth be told I don’t know what the hell I’m doing! I WISH I could be one of the greats who preaches the gospel of “Just install Linux” and who didn’t constantly ponder flashing stock android again. However its not that simple.
I’m a power user at best! Half the time I’m copying and pasting commands into the terminal. I try to smile when the Battle.Net launcher fails and buggs out through Lutris and tell myself “Its OK! Who needs to play WoW anyway! I’ll just replay Half Life again!” But in reality there’s a part of me that wants to just restart into my dual boot windows 11 partition with my tail between my legs.
I’m not worthy to be on Lemmy! DONT LOOK AT ME! (I’d type a crying Emoji, but my Foss degoogled keyboard doesn’t have Emojis)
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.
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
https://foxnews.com/tech/new-android-attack-tricks-you-giving-dangerous-permissions
> #GrapheneOS, a security-focused operating system based on Android, confirmed that its current version is also affected. However, it plans to release a fix in its next update.
No, we said that on July 7 and then shipped https://grapheneos.org/releases#2025070700 fixing it on the same day.
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.
https://foxnews.com/tech/new-android-attack-tricks-you-giving-dangerous-permissions
> #GrapheneOS, a security-focused operating system based on Android, confirmed that its current version is also affected. However, it plans to release a fix in its next update.
No, we said that on July 7 and then shipped https://grapheneos.org/releases#2025070700 fixing it on the same day.
The researchers reported it to Android on October 31, 2024 and Android still hasn't fixed it. We fixed the vulnerability by only allowing third party apps to use custom activity animations for their own activities. It's likely Android doesn't want to remove part of the feature.
Android 16 was released June 10 and we'd already done our final Android 15 QPR2 releases with backports of Android 16 drivers/firmware when we were informed about TapTrap near the end of June. Once our port to 16 was near Stable, one of our devs spent a few hours fixing TapTrap.
https://foxnews.com/tech/new-android-attack-tricks-you-giving-dangerous-permissions
> #GrapheneOS, a security-focused operating system based on Android, confirmed that its current version is also affected. However, it plans to release a fix in its next update.
No, we said that on July 7 and then shipped https://grapheneos.org/releases#2025070700 fixing it on the same day.
A lot of the team do not know what Nostr is as well. It's just me on my lonesome over here. It's going to take a moderate amount of time to see what developers think.
What to look out for when #GrapheneOS updates to Android 16 QPR1 in a few months.
Devices lacking standard privacy/security patches and protections aren't private
Scroll down when doing a call, and see if it shows up. The scrollbar will be made always visible next update.
I see the record buttons and we still have the feature. I'll report elsewhere and see if it shows up.
WebAssembly hard depends on JIT in the browser. Same actually applies to Chrome and such. JIT bugs cause a lot of exploited in the wild vulns so its disabled by default for hardening.
You can toggle JIT off per-site on the top left menu. The site loaded for me after using that.
Microsoft Edge has a JIT-less wasm interpreter they tried upstreaming but Chrome ended up not keeping the work upstreaming so its just an Edge thing.
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've decided to make another release today with our fix for the Android tapjacking vulnerability because we need to fix a DisplayPort alternate mode regression specific to 8th generation Pixels which doesn't impact 9th generation Pixels.
More bullshit from authoritarian sympathetic media. The vast majority of these abhorrent demographics are not using #GrapheneOS and they don't know what it is:
It is hilarious that the picture attached barely shows phones that look like Pixels, with weird camera bumps, headphone jacks and colour schemes? Am I supposed to believe this? Based on what is being said, these people are still getting charged (obviously, real world crimes have far more physical evidence than digital evidence), and so what? Why even associate us like this?
Why talk about an operating system like this? Where is all this press for other privacy and security operating systems? Numerous nonprofits around the world and journalists use GrapheneOS as their first choice because it keeps them safe. This kind of press trying to associate our name with crime is unacceptable, unprofessional and authoritarian.
If you play by their standards: Is Snapchat or Telegram crime software because it is an open secret that drug dealers in local areas love to use it? Is Discord or Twitter a service for predators because it's so egregiously popular and their design centered around publicity makes it easy to find accounts run by vulnerable demographics?
I haven't interacted with Tropic Square in any capacity nor do I think it has been an idea to use in a GrapheneOS device simply because there's no largely available 'product' and there would be a lot of developer work. I don't know about other team members interactions.
ATM our expectation is Qualcomm is going to add MTE to Snapdragon this year and OEMs willing to provide timely patches would mean a lot more devices would be meeting our standards in 2026. We're in contact with an OEM to make a GrapheneOS variant of a phone with a next generation Snapdragon flagship that can hopefully come in the coming years.
Snapdragon flagships have a basic secure element, but it wouldn't be as secure as the Titan M2, but it is sufficient at a baseline. This is the most likely alternative for the next non-Pixel GrapheneOS device. Snapdragon does other things better outside of secure element though.
Discussed it in the past but it would be more realistic to have a phone that just has a separate HWW like a Trezor attached at the back of it with some kind of hardware switch to power it on and connect it to the host device.
It already works fine as a separate device, so it likely wouldn't sell because of it being a gimmick. Also wouldn't fit some threat models because it's being used out in the open. Personally id still get one for the novelty.
For the later future Tropic Square could be interesting for what you want. Although, all the AOSP APIs would need to be developed for it in our use case (such as Weaver throttling, insider attack resistance setting and the Keystore) to have a smartphone that uses it.
More likely we'd have a new device from an OEM before the possibility of that.
The Pixels' RISC-V Titan M2 secure element is mostly derived from OpenTitan. Google committed to open sourcing the Pixel specific changes they made to OpenTitan a long time ago but it still hasn't appeared yet...
Welp
#GrapheneOS
Assuming no if they aren't providing them for current devices anymore.
If they decide to make it even more difficult than it becomes already. We are not the only project hit by this. The porting will be slower as more work to do. But the Port should be doable.
Would have to see what kind of state the Pixel 10 is in, although it is not out yet.
In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable. Android 16 launched today and porting is going to be significantly more difficult than we were expecting.
We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports.
Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making #GrapheneOS devices sooner than we expected.
We don't understand why these changes were made and it's a major turn in the wrong direction. Google is in the process of losing multiple antitrust cases in the US. Android and Chrome being split into separate companies has been requested by the DOJ. They may be preparing for it.
We're hard at work on getting the port to Android 16 done but there's a large amount of additional work we weren't expecting. It can be expected to take longer than our usual ports due to the conscription issue combined with this. It's not good, but we have to deal with it.
Having our own devices meeting our hardware requirements (https://grapheneos.org/faq#future-devices) would reduce the time pressure to migrate to new releases and could be used to obtain early access ourselves. Based on talks with OEMs, paying for what we need will cost millions of dollars.
A port to Android 16 is still being developed, it will just take longer. See:
Users of #Obtainium may be interested in this web site: https://www.openapk.net/
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 https://apps.obtainium.imranr.dev/
A better last resort option should app stores not be sufficient.
LibreOffice Calc in #GrapheneOS Debian VM running on an external display in the launcher with 'freeform windows in external display' switched on:
Gnome Debian desktop running on my Pixel 6a
https://v.nostr.build/vRonGqS5Vh47bywT.mp4
I installed gnome-core and virgl-server, it just worked 😂 Holy shit! Brilliant work by the GrapheneOS team.
#android #linux
Footage of GNOME, Firefox and Doom running within #GrapheneOS Linux virtual machines.
As a preview of what's going to be possible in the upcoming release of #GrapheneOS, here's a screenshot from a Pixel Tablet running desktop Chrome in a virtual machine with basic GPU acceleration via ANGLE on the host. The infrastructure is a lot more robust than the Terminal app:
Our next release also enables running the Terminal app in secondary users. There's still the temporary limitation of only being able to use a single VM on the device at a time because the dedicated internal network interface it uses for the Terminal app isn't split up at all yet.
GUI VM support will have 2 main use cases:
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.
This virtual machine management app (Terminal) will be handling the 2nd case. It's essentially already available in a very primitive way. We expect this to become much more usable and robust entirely from the upstream Android work on the virtual machine and desktop mode features.