I just installed Graphene on a new pixel. I've only used it for two days, but I got that same feeling of "finding buried treasure in your backyard" I got when I first installed Linux in 1999. I can't believe this amazing software is free in all senses of the word. It is a TON of work and they got so much right. The security and usability settings give all the grainular control I've known was possible and wanted for a long time.
I see some core team on this thread, so just wanted to say THANK YOU! Awesome job! Keep fighting for the users!
I'm totally the wrong person to offer recommendations on mobile, but so far it works very well for me, but then, I use almost no third party apps, and none of them are Play store only. My only complaint is the hardware (outside of their control).
I got it installed last weekend, really powerful mobile OS.
I did do about three weeks of research, as I worried that maybe a number of apps wouldn't run on it or needed some form of deep attestation. Didn't find much, OpsGenie and other work apps are happy with the GOS level of attestation provided.
Great to have Google kicked off the phone. So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
One tip from me, if you came from stock Pixel: You can download the default Pixel sounds and set them up like it was. Have a look for "Your New Adventure" online, the message sound is "Eureka".
I've got a Pixel 9a expected to arrive today, specifically for it to run GrapheneOS. One of my old phones was a Nexus 6P running CopperheadOS (prior to the dispute that spawned GrapheneOS), and it was great back then. Looking forward to how things have progressed in the years since.
I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.
Except the default browser is Chromium with some changes
This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that
Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else
It even offers a sandboxed Google Play Store
It tries to copy Google paternalism
It swaps a Google mothership for a Graphene mothership
What if the computer owner does not want a mothership
Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access
If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
Most apps but not all will try to connect to the internet at some point, even if you never use them
The user-hostile design of Android is that apps keep running in the background after they are "closed"
(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)
Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.
One does not even need Netguard to see this subversive activity
Try this at home
Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD
Put the phone on the same network as this computer
Set the phone's gateway address to the address of the computer
Run tcpdump on the computer and filter for the phone's IP address
> So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
For those of us who aren't ready to cut the umbilical cord to the mothership, you can also root/firewall on normal android to stop this. In fact I choose to not be able to use banking apps in order to cut out the crappy ads.
> I can't believe this amazing software is free in all senses of the word.
I wish that were true, but if you delete the 100s of binary blobs (many with effectively root access) copied from a stock donor vendor partition the phone won't function at all.
There is no such thing as a fully open source and user controlled Android device today.
It's not all grim. GrapheneOS utilizes IOMMU to isolate the baseband and sandbox the wireless components. Even with binary blobs, the wireless radios cannot read encrypted traffic.
Sure, it's not perfect, but it's still really, really good. Even with the binary blobs that are on it, Graphene phones have been impossible to unlock via commercial cracking tools since 2022.
Let's not allow the perfect to be the enemy of the good. GrapheneOS does what it can to isolate those things as much as possible. It even makes good use of hardware features such as the IOMMU. It's a huge improvement on the status quo, even though it's not going to pass FSF RYF certification.
Laptops, desktops, smartphones or tablets are closed source hardware with closed source firmware in general. There are products marketed as if they're open source devices which are in fact closed source hardware with almost entirely closed source firmware. The software on top being open source is frequently misrepresented as the device itself being open source, which isn't the case. Not shipping important firmware updates in the OS provides assurance of insecurity while not changing the fact that the hardware and firmware is closed source. It has to do with a loophole defined in a certain ideology around software, not open hardware or privacy/security.
Mock Location is a standard Android feature available in GrapheneOS. Our upcoming Location Scopes feature is being added for per-app control rather than global.
It's fairly pointless for apps to check for Mock Location being active without also verifying the OS via the Play Integrity API or hardware attestation API. Most apps checking for it are using or in the process of adopting the Play Integrity API. Apps enforcing the Play Integrity API basic/strong integrity level won't work on GrapheneOS unless they explicitly allow it. A growing number of apps doing this are explicitly allowing GrapheneOS. It would be counterproductive if our Location Scopes API didn't provide a way for apps to check if since those apps simply wouldn't permit GrapheneOS. However, it doesn't need to be the existing Mock Location API. It can be our own API which would only be used by apps explicitly choosing to permit GrapheneOS. This would allow apps like Pokemon Go and Ingress to permit GrapheneOS even if they insist on not allowing directly spoofing location.
My understanding is that Mock Location on android is a developer setting that apps can easily check for, and as such, is basically useless (it will not fool any app that is asking for your location).
I hate that many banking apps refuse to run on non-Google OSes. I can see that my banking app doesn't even work on GrapheneOS based on the link given in a sibling comment. It makes absolutely no sense from a security perspective since I am still able to log in using the browser, and the web app has the exact same UI and authorization flows as the actual app.
It all seems like a security theater with the consequence that, ooops, we just vendor locked in all our customers to run a less secure OS by a company whose business it is to collect personal data and show ads that people don't want to see.
I'm always afraid of my phone getting stolen or losing it somewhere so I have a completely separate iPhone, which runs my banking apps. I keep that phone at home.
It depends what banking apps you use. Some are available. From my observation major banks in Poland work just fine. You can pay via NFC using the mBank app if you need to. Revolut also works fine. gPay just doesn't work however therefore you cannot pay with this via NFC.
I use my Garmin watch to pay for all things in physical stores anyway, so no need for NFC payments anyway.
Have a second profile with fewer restrictions for those apps you think you need but don't want to compromise security for. My second profile has one app, which is my banking app with all the dependencies it rudely requires for functionality
Happy long term user, great project. Here is a list of Open Source Apps, I use to replace Google stuff:
Aurora Store - Anonymized frontend for Playstore
F-Droid - Open Source App Store
Obtainium - App Store for other sources (e.g. github)
Organic Maps - Open Source navigation (not as good as proprietary ones though)
SherpaTTS - Text to speech for Organic Maps
PDF Doc Scanner - Little Trickster, Open Source document scanner
Binary Eye - Barcode reader
K9 Mail / FairMail - Mail client
LocalSend - Cross Platform File Transfer
Syncthing Fork - Catfriend1 Syncthing fork to sync files
VLC Media Player - media player
KOReader - ebook reader
Voice - Paul Woitaschek, local audiobook player
AudioBookShelf - Remote audiobook player
Immich - image backup
Fossify File Manager - file manager
Substreamer / DSub - Audio streamer for navidrome self hosted server
OpenCamera - Open Source camera app
I wish I had this list from the start... Hope it helps someone :-)
> Organic Maps - Open Source navigation (not as good as proprietary ones though)
Note that a community fork done by some core contributors was just spawned: CoMaps [1]
> K9 Mail / FairMail - Mail client
And now there's Thunderbird, which is branded version of K9 Mail IIUC (I don't know if there's any reason to switch from K9 Mail to Thunderbird for existing users)
Does the fork solve the issue with inputting addresses? Organic Maps will happily route to the correct street, but falls over when entering a standard format address (i.e. XXX Streetname Ave)
PassAndroid: to open apple/android wallet files (airplane/cinema tickets etc.)
Find My Device (FMD) on F-Droid: replacement for the google version, works via sms commands or a self-hosted app
AntennaPod: Podcast App
Breezy Weather: with multiple weather sources, great ui
How do push notifications and similar things work on GraphenOS? Do they work reliably out of the box on most apps, or did you have to set up MicroG/whatever GrapheneOS's equivalent is?
> How do push notifications and similar things work on GraphenOS?
Some apps require Google's FCM for push notifications. You need to install Sandboxed Google Play services from the GrapheneOS App Store and grant them unrestricted battery access (so they can run in the background, which is required for maintaining a network connection to FCM and delivering notifications). https://grapheneos.org/faq#notifications
Other apps like Signal use their own background connections, for example WebSockets, to deliver push notifications, but keeping a connection open for each app consumes more battery life than just having one background network connection. Also, not every app supports this.
For Signal specifically, the GrapheneOS project recommends either using FCM via Sandboxed Google Play, or installing Molly (https://molly.im/), a fork of the Signal client for Android, which makes some changes to reduce battery consumption when using WebSocket-based notifications. It also allows you to use UnifiedPush (https://unifiedpush.org/) for notifications instead, but that requires an application called mollysocket (https://github.com/mollyim/mollysocket) running on a server.
Push notifications work on GrapheneOS whether apps do it themselves, use UnifiedPush with the user's choice of provider or use FCM. UnifiedPush and FCM are a more efficient design where apps share a push connection. Unfortunately, many apps only support FCM and some support their own push as a fallback, but few support UnifiedPush. FCM works very well via sandboxed Google Play, which is an approach where Google apps can be installed as regular sandboxed apps with zero special access or privileges. Nothing FCM does actually requires special privileges and our compatibility layer makes it work without it.
GrapheneOS does not include sandboxed Google Play but rather includes an open source compatibility layer providing support for installing Google Play as regular sandboxed apps. They can't do or access anything more than other apps including the Google Play code running inside apps using Google Play which is the reason for choosing this design. It simply uses the same app sandbox and permission model which are both greatly improved by GrapheneOS for supporting running the rest of Google Play not bundled with apps using it.
Worth noting apps don't need Google Play services to use Google services and many Google libraries like Ads and Analytics work without it. FCM requires Google Play services but many of their libraries do. There are Lite variants of Ads and Analytics for keeping apps smaller which lose the ability work without Google Play services. The general reason for the design is they don't want to have huge apps and want to be able to update the clients for their services without app developers doing it and shipping an app update. FCM is one of the special cases requiring the central design for efficiency. UnifiedPush is an alternative with choice of implementation / provider.
Everything works out of the box, and it doesn't use a third party layer like MicroG. The difference is that Google's apps/services are not given admin privileges like they usually are, so you can selectively enable or disable things.
For example, installing an app on Google Play works like F-Droid. Once the download finishes, you have to open the Play store app to trigger a system dialog to accept the installation. On other Android devices, GPlay can install apps without your approval.
Does the NextCloud app now sync contacts and calendar? Last time I tried, years ago, it did not. I use DAVx5 to sync my NextCloud contacts and calendar, via CardDav and CalDav.
Absolutely. You can basically get almost the same experience as you would on a stock OS device, but with much better privacy. On the stock OS, Google apps get privileged access, so they can still access photos and your camera and all that, but what people don't realize is that their privileged access also includes things like usage data, hardware identifiers, etc. Using Google apps on GrapheneOS makes a lot of sense.
The only problems you might run into would be some features might require privileged access, things like Now Playing. Makes sense because normal apps cannot have unrestricted access to the microphone like that. Google Wallet works, but you cannot make payments because the app refuses to work on alternate OSes.
Besides that kind of stuff, though, I've used all sorts of Google apps without issues.
Over the years, Big Tech has given me reasons to trust them less and less. So I encourage you to be a rebel: cut Google out and live outside the system.
Last I heard, Google discontinued publishing device trees and driver binaries for Pixel devices with their recent changes to their stewardship of the AOSP [0]. Was it something definitive or are they merely delayed? If the practice is being discontinued, what would be the reason why? Doesn't publishing these artifacts create a business case for customer demand for the Pixel devices? Or is there some cost that outweighs the benefits? Is it maintainer overhead?
I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!
Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. A few OEMs publish more basic device trees for older Android versions. This was Pixels losing one of their advantages compared to non-Pixels but it was never one of our hardware requirements, which are listed at https://grapheneos.org/faq#future-devices. It isn't part of why Pixels are the only devices meeting our requirements. We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.
GrapheneOS typically ports to new yearly Android releases in a couple days and tends to have it reach the Stable channel in under 2 weeks. We completed our initial port to Android 16 in a similar time period after the release on 2025-06-10. However, we then had to reimplement device support in a similar way to how we would support a non-Pixel device. Our initial production release based on Android 16 was published on June 30th. As usual, we had to spend around a week making a series of releases fixing regressions reported by users. It reached our Stable channel on July 8th.
Since our port to Android 16 took significantly longer than usual, we backported most of the Android 16 firmware, all of the kernel drivers and parts of the userspace device support to our now obsolete Android 15 QPR2 branch and did a few more releases based on Android 15 QPR2 where we were able to provide the full 2025-06-05 patch level which also turned out to be the full 2025-07-05 patch level due to no vulnerability fixes in the July 2025 Android Security Bulletin or Pixel Update Bulletin. This was an unusual approach and not generally a reasonable way of doing things. We were able to do it successfully.
It won't be nearly as much of an issue going forward since we dealt with building the new automation we needed. Our port to Android 16 QPR1, Android 16 QPR2, Android 16 QPR3, Android 17, etc. shouldn't be nearly as difficult and we should get back to our typical porting time for major releases.
Quite a lot of detail on this comment, thanks for that!
But I'm still left a bit confused about the future devices GraphaneOS will support:
Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?
You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?
As you're working with the OEM, I hope you'll consider a model which will come with either an IPS screen or is compatible with a 3rd party IPS replacement.
I bought a Pixel 9 Pro Xl specifically to use with GrapheneOS. Unfortunately, its OLED and my eyes were incompatible. The PWM on the screen was terrible and I had to return it after some headaches.
Of course, none of that was the fault of GrapheneOS. I absolutely loved using it and think your project is vital.
I suppose this means that supporting future Pixel devices will be more difficult? If someone has the ear of anyone at Google, especially someone who works with Android, please share this cause with them!
I heard unsubstantiated rumors that it was somehow antitrust-related. If they are selling off their device business (again), then it makes sense that the device drivers would not be part of AOSP...
Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.
It may be permanent and I think this was the official indirect response:
"AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0]
Emphasis on independent of any particular hardware.
Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]).
The main missing feature is password under duress that would open a different “user”. So even if you’re forced to give away your password they won’t get to the real account (some hidden profile or similar).
At least hidden profiles would be good enough for basic protection.
GrapheneOS community manager here. The problem with something like this is that it cannot be reasonably hidden when it would be exposed by someone using basic tools. Our Duress PIN/Password feature doesn't make any attempts to mask itself, precisely because we think doing that only gives people a false sense of security.
We think there's a good chance a motivated adversary is going to be familiar with GrapheneOS and its features, and the more mainstream it becomes, the more this can mean "your abusive significant other" rather than someone at the border.
The moment people know this feature exists, it can become dangerous even if you don't use it. You can be threatened to unlock, and even if you do, the adversary can choose to not believe you since they can think you're just hiding it. That puts you in a dangerous situation where they think you can provide something that's literally not there.
It's a very difficult problem to solve, and we don't think that proposal can solve it.
I hate to say this but I don't foresee Graphene being "mainstream". Most users will stick to the stock ROM. The most "mainstream" custom ROM Lineage is only installed on 0.04% of Android devices as of 2023 [1]. Even if Graphene appears in some mainstream news, I highly doubt any ordinary person can recognize it when they see one.
If the threat model is hiding from random people, I think a hidden profile works very well.
Now let's talk about motivated adversary as you put it. Hidden profile and wiping are not either-or, they can coexist. If one is really targeted by a motivated adversary, it should be apparent in most cases, and the targeted person can choose to enter the wiping PIN instead of the secondary profile PIN.
Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
Tbh I’d say 99% of the criminals won’t know about this.
Let’s say someone have you at gunpoint, you can just give your mains profile pass.
If they don’t even know there is a secret profile you’re good to go.
You’re right, they might assume you’re hiding, but I’d say 99% won’t know what’s even graphene and from those who know I’d say they might force you and you can have 3 sets of bank accounts:
Main profile: 100
Secondary: 1000
Terriary: $$$
Also if you hide all traces of grapheneos would be safer too. Nobody even knows is graphene, so they can’t even check what features you have. Again we are talking about 99% of the criminals, not the tech savvy 1%.
I’d prefer plausible deniability like Vera crypt than what we have now.
There are certain threat/risk models where having multiple profiles might be helpful (non-forensic examination by an offical at a securtiy screening kinda scenario). But you're right, it's nuanced, requires know-how by the user, and possibly a foot-gun for some caught unawares. NOT an easy problem to solve. Personally, as a user, I'd like the ability to be able to choose that option in the instances where I needed it, but it's likey a TON of work for a very small actual user community who needs it.
I think this feature nowadays would be mostly for the border control checks, especially in the US. Basically to avoid being sent back over a JD Vance meme found at a glance, as opposed to actually being held hostage.
I remember a conversation with a political activist refugee. They were in a group of people who got checked at the border, and were asked to unlock their laptops. The border security personnel then proceeded to do a short inspection of the visible systems. They all used Veracrypt's Hidden Operating System functionality, and while it would be trivially detectable, the border security did not, so they got through without problems. If they had refused to "unlock", or used a duress passphrase that wiped the system without presenting a dummy version, they would have been held, possibly for a very long time, and definitely not allowed to exit.
Moral of the story: Different contexts allow for different solutions. It is a sign of false privilege to make assumptions, and not let the user decide. An argument can be made in terms of priority of implementation, but not in terms of "pointlessness". The often used argument of "false security" can be addressed by warnings; yes, some people may not understand the implications, but you do not need to make their own (bad/good) choices for them; that's paternalism, not care.
In the real world, where thanks to my political work I am in contact with many people who had to endure real-world security checks, police raids, investigations, and so on, in all the cases no proper (imaginary) forensic analysis was performed. People make mistakes and remain uneducated -- on both sides. The "But NSA!" argument brought forward typically by white techbros kills a lot of useful technology before it even exists, which is unfortunate for those that would actually benefit from it, and when asked would tell you so. It's also not either/or in reality: In many situations, it will buy you time (while e.g. your lawyer may try to get you and your devices out of the situation), and even if they find out you were trying to fool them, they may give you another chance, and then you can still opt for the wipe code. It makes a huge psychological difference to have multiple options and feel in control.
This hyperbole is extreme, and unnecessary. If your life depends on the ability to simulate a fake user on a phone, there are more significant problems than a lack of operating system features, and a general failure to defend in depth.
This is a fully general argument against any single thing your life might depend on: seat belts, defibrillators, bulletproof vests, etc.
If the only thing protecting you from getting shot to death is a bulletproof vest, clearly a lot has already gone very wrong, and you're likely to die today anyway. But that kind of thinking is exactly what leads to a failure to defend in depth.
GrapheneOS Discussion Forum: "This site is best viewed in a modern browser with JavaScript enabled. "
Security my ass ...
To "GrapheneOS community manager" - please fix this. Where is .onion site?
Security doesn't mean you have to go feed the cows and leave behind everything.
In fact, a core aspect of security is having access to a feature in the very first place.
A forum, being hosted on the web has absolutely no reason to stay away from the de facto scripting language of the platform. What would be your threat model for that forum? A zero day that would break the whole world?
It is possible to view the forum without JavaScript being enabled, but not sign in and post. We use Flarum for our forum, and that's a limitation of the platform.
We use Flarum as our forum software for https://discuss.grapheneos.org/. Flarum supports viewing all of the content without JavaScript via an HTML fallback mode using pagination. Flarum simply informs people they'll have a better experience with JavaScript enabled.
I have used LineageOS [0] for a few years on my old phone, and last year I got a Pixel 4 and I am using Graphene on it. Both systems work well and I am really glad they exist; Graphene gets extra points for its extremely easy installation process. Unfortunately it seems Graphene is already phasing out support for the Pixel 4 [1], so I'll have to switch back to Lineage at some point.
The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
Pixel 8 works amazingly with Graphene's new network location feature. Position fixes are SO MUCH FASTER. It is truly a gamechanger. First it was Wi-Fi only, but they just released cellular location as well. They provide a proxy to Apple's location services.
>>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost
> Graphene's new network location feature
I believe it uses https://beacondb.net/, which is starting to have fairly decent coverage, at least in large parts of Europe. You can contribute to BeaconDB even if you have an ordinary Google phone by installing https://github.com/mjaakko/NeoStumbler.
I use LineageOS myself (because Graphene no longer supports my Pixel 5), and unfortunately it doesn't do network location out of the box. You can get network location on LineageOS by installing MicroG, but it's currently somewhat flaky.
My only problem with Graphene is the ridiculous low number of supported devices, i know I know, security reasons and so on. But I would accept an lower security hardened version but at least have Graphene instead of Google's junk
However, we're currently working with another OEM and are hoping to have a device of theirs meet our requirements that can be launched in 2026 or 2027. Nothing set in stone, but we're optimistic thus far.
Extremely happy GrapheneOS user here. Thank you so much for the work you and your colleagues do. Speaking for myself, the adoption of a mobile communication and computing choice that both put me in control of what information I interact with and respects my agency enough to present me with the hard choices about what I do and don't want for myself has been a life-altering upgrade in something midway between "peace of mind" and "outright mental health".
Much like you don't hear the sound of a busy city until you go somewhere truly quiet, you don't remember owning your own brain until you evict all of the entities who have been living rent free in it.
Keep doing the great work you're doing: it's making people's lives better in dramatically more significant ways than most software.
I can understand the GOS' rationale in choosing only the most secure phones. However, I'm more concerned about privacy, and not so much about security. It'd be great to have something like a "GOS-Lite" which accepts some security compromises in order to bring privacy to more people. (And yes, I understand that lower security means less privacy from targeted attacks but even GOS depends on OEM blobs, right?)
If it's a repairable phone like the Fairphone, that would be fantastic. Otherwise, I'm already very satisfied with what you offer. Thanks for you work.
I had to Google this. Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag? Or are you only interested in the memory safety benefits? Regardless, why target requirements that even most desktop computers don't meet?
About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.
What's ridiculous about it ? There are now 4-5 gens of Pixels with their major/minor bumps too (A series, pro, etc.). There's enough variety at different price points for everyone there.
CalyxOS downgrades security compared to the Android Open Source Project, often falls significantly behind on standard Android privacy and security patches as is the case right now (they still haven't ported to Android 16 which is required to have the latest patches) and doesn't provide similar privacy or security features.
Features like Contact Scopes, Storage Scopes and our Sensors permission toggle are some of the privacy features includes in GrapheneOS.
Privacy necessitates security. The security provided by GrapheneOS is in order to be able to protect privacy.
GrapheneOS community manager here. Google did make it harder to support Pixels, but we're still doing it and plan to continue supporting new Pixels provided they keep meeting our requirements.
At the same time, we're in communication with an OEM to have some of their devices have official GrapheneOS support, so we're moving towards redundancy.
I actually like Graphene's focus in Pixel. It is available in a lot of countries unlike Fairphone - via Pixel of course.
So Graphene is actually not limited to the developed/western world. As for not supporting other devices, I believe the reason could be the team size and the fact that the fragmented Android world is known for unique shenanigans of every OEM. Besides Google's update/upgrade cycle is another reason it is an appropriate choice.
It's a shame that Android as a whole is trending towards hardware remote attestation. It's pretty much guaranteed that app developers will eventually start writing their apps so that they refuse to run on anything that doesn't pass Google Play Integrity. Being unable to run WhatsApp or bank apps on GrapheneOS will render it useless as a smartphone operating system. It might not be happening right now but the threat of it looms eternal. My bank could flip a switch somewhere and suddenly my phone becomes useless for the purpose of accessing my bank account.
The Google Pixel requirement also makes me sad. I understand that they have solid reasons why. The problem is Google is incapable of selling their phones worldwide. It's really embarrassing for Google and unfortunate for me.
Not at all. They are one and the same. Both of those things will literally destroy the computer freedom we enjoy today.
GrapheneOS can attest to the device's security. The question is whether the app developers will trust such an attestation. Will they put money, time and effort into evaluating and trusting GrapheneOS? Of course not. They will just decide to trust nobody except Google and Apple.
This is the future. We'll be discriminated against. Can't even log into an account from an "unauthorized device". Their servers will just refuse to talk to our phones if they can't cryptographically verify that we have not "tampered with" them. We'll be refused service straight up unless our computers are straight up owned by corporations.
This so called "integrity checking" is meant to protect the corporations from us, not the other way around. It's so we can't do things like hack our way around their "policies".
I think Graphene gets posted here yearly. Having tested a variety of ROMs dedicated to different elements of security, I can attest that Graphene allows the most "normal" phone usage compared to many others. The biggest factor is the sandboxed Google Play Services, which allow you to use a lot of apps that you wouldn't be able to otherwise.
I've used Lineage without MicroG, as a comparison, and that's becoming more-and-more unusable every day some lousy Android developer tethers their company's app to some feature exclusive to Play Services.
Google Pay is not available on any alternative OS due to Google blocking it. It's unfortunately their choice, rather than a lack of support on our end.
Depending on where you are in the world, there might be other NFC payment options for you.
In the EEA and UK, Curve pay works. Paypal made their own solution and is rolling it out, starting with Germany. Both work with GrapheneOS. Many banks also have their own solutions.
It's interesting that the only devices complying with the security requirements are Google's.
I wonder if Google actually has an internal version of Android that's more security-focussed. Given that critical engineers' personal devices being hacked should be a security threat that's on Google's radar, it's possible.
As a large company, they are probably targeted through their devices and since they have the means, it does make sense that the Pixel devices have high security standards compared to other OEMs.
Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. There are a small subset of other devices with at least nearly all of the security features we require. However, those devices either don't allow using another OS or cripple security for it. There's no other device providing the listed security features and allowing us to support it. Pixels are also the only devices properly keeping up with current Android OS and security updates. We need ongoing firmware and driver updates. There are other devices offering support for a similar time period, but not actually providing close to the same thing during that time period.
Most OEMs do the bare minimum for security. The security features they provide are the ones provided for them by AOSP, the SoC vendor, etc. They provide delayed and quite incomplete security patches.
Android downplays the fact that it has OS releases every month. There's a new monthly, quarterly or yearly release each month. The monthly Android Security Bulletin patches are a separate thing providing backports of a subset of the security patches (most High and Critical severity AOSP patches) to older initial yearly releases (the initial releases of Android 13, 14, 15 and 16). There are also a huge amount of SoC and other hardware-related security patches with a small subset included in the Android Security Bulletin. Most OEMs struggle to provide these backports and vendor patches on time for a reasonable time period. Non-Pixel OEMs eventually update to a new initial yearly release, usually quite late, then rely on the backports to it for a year or more. Full Android security patches mean shipping the latest stable releases, which have been through significant public testing beforehand for quarterly/yearly releases and are not actually bleeding edge. Quarterly releases are as large as yearly ones but awareness of them existing is low. Android 16 QPR1 currently in Beta has more user-facing changes than Android 16.
We're working with a major Android OEM towards some of their future devices meeting our requirements and providing official GrapheneOS support. It will be their regular devices but meeting our requirements currently only Pixels do. Hopefully available in 2026 or 2027. There's no reason other devices can't provide comparable or better security than Pixels, but it's not easy or cheap.
Why do you think that's interesting? Google is highly respected for its security practices. Do you think Apple engineers use some special hardened iOS?
I am a long time GrapheneOS user, amazing project. One thing that is not clear to me is the support for NFC payments. Las time I checked, NFC payments on Graohene didn't work at all, but I am reading on this thread that some users do manage to pay via NFC? Did Iget this right? Mind explaining how?
I do not use banking apps (I only use banks that allow me to log in via browser using a 2FA which is not a proprietary app, like a FIDO key or other physical dongle), but do I get it right that Revolut would allow me to pay via NFC in this case? Is this something geo-dependent?
The issue isn't with NFC. It's passing the Play Integrity check that app developers optionally can use to prevent devices that don't pass the check from running their app, or remove parts of its functionality. IIRC I don't think any custom ROM's can pass the check. So you might be able to pay via NFC with a banking app if they don't implement the Play Integrity API. For Graphene's thoughts on the matter (2024):
NFC payments work on GrapheneOS. Curve Pay works with GrapheneOS and is available in the UK And European Economic Area (EEA). PayPal launched tap-to-pay which works with GrapheneOS but has very limited regional availability. Many European banks provide working tap-to-pay with GrapheneOS.
The issue is apps banning using a device not licensing Google Mobile Services or a non-stock OS via the Play Integrity API. Google Pay does this and a lot of banks outsource tap-to-pay to Google Pay instead of providing their own like many European banks. GrapheneOS users in Europe have multiple options. Users in the US often use a smartwatch for this purpose which includes the option of Garmin Pay rather than only Apple Pay and Google Pay.
The choices depend on the region. It would be nice if the Play Integrity API was forced to permit GrapheneOS via hardware attestation verification by regulators. We're pushing for it in Europe.
- Adding your card to Google Wallet.
- Using a banking app which actually implements payments via NFC.
Many banks used to implement the latter, but dropped it in favour of "just use Google Wallet". In the Netherlands, it seems to be all of them. This varies a lot per region.
I believe that the "just use Google Wallet" banks are the ones that don't work.
Also (as others have mentioned): many banks perform integrity checks, to ensure that you're using a software chain signed by Google.
> ""will never again be closely tied to any particular sponsor or company"". Work on GrapheneOS is supported by a Canada-based foundation created in 2023; there appears to be almost no public information available regarding this organization, though.
The company you're discussing is... GrapheneOS itself.
> GrapheneOS Foundation was created as a non-profit organization in Canada in March 2023 to handle the intake and distribution of donations. [1]
> GrapheneOS Foundation has been incorporated as a federal non-profit organization in Canada. It will be used to receive donations to pay developers and pay for infrastructure. It will also help to shield developers from attacks through the legal systems across various countries. [2]
A question for strcat / other Graphene developers:
Can you clarify what can one expect from legacy extended support. Will old devices get any more updates? how long, how often, is it just security patches etc..
Not a dev, but legacy extended support means that there are no more feature updates, i.e., no new Android versions or QPRs, only AOSP security backports.
Obviously there aren't any firmware patches either, as these devices are unsupported by the manufacturer, who is responsible for delivering any changes to the firmware.
If I need to buy a phone made by Google to get away from Google, I'm just not doing it. /e/ doesn't support my current smartphone, either, and postmarketOS is not functional. At this rate, I think we're better off going back to dumbphones.
Even if you aren't concerned about the possibility of "backdoored hardware" (and I am not, for one), I'm still sympathetic to the argument that giving money to Google is morally wrong because it provides financial support for their data-harvesting business model (though since you use GrapheneOS, they'll only be able to use it to harvest other users' data, of course, not yours). Buying a used Pixel doesn't support Google financially, so perhaps that's more ethical.
Thank you. I have the same worry. I'm not a developer, how could one tell there isn't some built in backdoor in the hardware? There was another HN posting on Graphene and asked the same question there with no answer.
The same thing could be said about any hardware. Pixels receive by far the most privacy and security research of any devices. They're by far the most secure Android devices and the only ones providing competitive security with iPhones. They're the only devices with even a reasonable level of security combined with proper alternate OS support. Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. These are very reasonable requirements for industry standard security features, standard updates and the ability for GrapheneOS to use those standard security features. There are other devices with all the major features listed there but not the ability for GrapheneOS to use all of them. Updates are a major issue for all non-Pixel Android devices including the ones advertising lengthy support.
GrapheneOS is working with a major Android OEM towards their future devices providing the expected hardware-based security features and updates, unlike their current devices. The purpose of GrapheneOS is not specifically avoiding Google but if you want hardware from another large tech company to use with GrapheneOS, you'll have that option. The initial goal for these devices is providing a similar level of security and long term support to what we already have with Pixels. In the longer term, we want to have add hardware-based security features unavailable on Pixels or iPhones along with hardening below the OS layer.
For now, Pixels are the only viable option for us to use. We're actively working on changing that but we're not going to simply greatly lower our standards and support devices where we can't adequately protect users. There's no evidence of any backdoor and it's contradicted by how exploits are developed and used. There is plenty of evidence that other devices lack comparable security.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... shows an example where only the Pixel 6 and later / iPhone 12 and later have brute force protection which holds up against the most sophisticated company developing forensic data extraction tools. We have access to more recent documentation showing the same thing.
Why do governments buy exploit tools from NSO, Cellebrite, etc. and develop their own if they supposedly have backdoors in devices? Why would using a device from Samsung or Sony protect against it if they did?
I am (very slowly) migrating from iOS to GrapheneOS, for the same reasons as OP (privacy, Apple's increasingly user-hostile and developer-exploitative policies).
Apart from migrations concerns, which are not GrapheneOS' fault, the main shortcoming I see is the lack of proper backup/restore, e.g. when switching phones. There is Seedvault, but I've found it unreliable.
Maybe my tinfoil hat is on too tight, but I always thought it was interesting that Graphene OS places so much blind trust in a proprietary black box security chip from Google that they pinky-promised to open source but never did.
Because they are a software project. When you're only concerning yourself with software, you have to pick some hardware and move on.
Going down the rabbit hole of secure hardware leads you down a slippery slope of eventually needing to create your own chips. And that's basically impossible these days for anybody smaller than Google or Samsung. So you do some research, pick the best you can, and hope for the best.
OpenTitan has open silicon (RISC-V) and is capable of open firmware (based on Rust TockOS) and is coming to 2025 Chromebooks, https://news.ycombinator.com/item?id=44416304. Hopefully a derivative of OpenTitan will ship in future Pixel devices.
Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.
Are you referring to the titan M2? why do you describe Graphene OS putting "so much blind trust in" it? I don't think they put much trust in it besides using it for storing keys and for their "Auditor" app
> I don't think they put much trust in it besides using it for storing keys
Ummm. Was this sarcasm that went over my head? Because if not, I have a hard time thinking of anything that requires as much trust as your private key storage.
If you think the org that produced the hardware might have backdoored it, architecting your software to avoid the TPM or whatever is dumb. Targeting Google HW at all is an unavoidable act of complete trust so you might as well use the HW properly.
Also, why would Google bother backdooring their special HW when 99.999% of its users are anyway gonna be running a totally Google-controlled proprietary SW stack?
> Targeting Google HW at all is an unavoidable act of complete trust
Doesn't the existence of FHE downgrade that to just "complete practical trust" at least? Not that I know of it being employed, but that it could be, and that it may be worth shouting out exactly cause of how niche and impractical it is.
Does anybody else here see as problematic that this OS supports mostly Pixel, a Google phone?
Over and again people on HN make the following argument: "Google is a company that makes most of its revenue from ads and surveillance. Therefore, you should always assume that Google is spying on you". But somehow when it comes to Pixel people give it a pass?
Prediction: If Pixel isn't already hardwired to phone home and report on your activities, it will slowly become so over time, as Google realizes its interest. You know, as it happened with Android, Chrome, and everything else that Google touches.
I think it's perfectly valid to consider this as problematic (the GrapheneOS team certainly seems to think this is not ideal, for example). However - somewhat counter-intuitively - it's also valid to consider Pixels as among the most secure and most appropriate Android phones for something like GrapheneOS.
Your prediction is about a hardware product, and your examples are both software products (one is a browser and another is a mobile OS, both of which are platforms for running other software, and thus extremely well-suited to the task of reporting user data back to Google).
I'm not an expert, but baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
> baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
This isn't really a practical way of doing it. Google Play and Google Play Services having privileged access is more than sufficient.
This is just conspiratorial fearmongering based on vibes. If pixels somehow phoned home on a hardware level, do you think we wouldn't be able to tell? Do you think we wouldn't see it in our network logs?
GrapheneOS supports pixels because they are currently the only devices that fulfill their list of requirements, like an actually usable secure element, hardware memory tagging, etc.
They have said and continue to reiterate that they would support other devices that fulfill their requirements and seem to be currently looking into working with OEMs to move away from pixels in the long term.
Just saying "you claim to degoogle phones yet the phone you use is a GOOGLE pixel, suspicious" is baseless nonsense.
> If pixels somehow phoned home on a hardware level, do you think we wouldn't be able to tell?
Yes.
> Do you think we wouldn't see it in our network logs?
If it's done on the baseband processor, no.
I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
But yes - your phone has a separate SOC, with its own operating system you can't access, which communicates with cellular networks. We don't know what, exactly, it's used for or what, exactly, is being transmitted. We do know it's used for location tracking because this is utilized by law enforcement somewhat regularly. But cellular triangulation isn't too accurate, not like precise location services.
I'd install Graphene OS in a heartbeat on my Pixel if they'd add support for Google call screening and feature like Hold for me. Thise features are why I bought my pixel and it's too much of an inconvenience to go without them now. Spam calls have went down significantly and has saved me a lot of time.
I believe spam detection in the Google Phone app does work on GrapheneOS.
For spam, install their sandboxed Google Play, and then install Google's Phone and Speech Recognition & Synthesis apps. For SMS/MMS/RCS spam, you'd use an app supporting blocking (e.g., Google Messages).
I imagine that Hold For Me works if you also install the Google app and whatever other dependencies.
Been using it for the past two years and supporting the project. I personally love it but you do have to tinker a bit once in a while so I would hesitate to put it in the hands of my parents (though I bought them pixel just in case). Google Pay not working is mildly annoying (hoping to get PayPal or Curve eventually). Android Auto works but I didnt yet try to make voice commands work. Some app behave weird if you block access to the sensors (though it is nice to be able to do it). Sandboxed google play works great for the most part.
My workaround for using both NFC payments and Graphene OS is wearing a Google Pixel Watch (1). All other Google Wallet features besides NFC payments should work.
Sadly that solution does not work everywhere. In a lot of countries, Google Pay cards are added by the bank's app and it's on the bank to support rolling out cards on WearOS as well. A lot of banks in my country only support putting a card in Wallet on phones, but not WearOS watches (not sure if it is laziness on their part or whether security of WearOS watches is not deemed acceptable in general due to the lack of secure elements, shorter/no PINs, etc.).
True, but unfortunately Proton Drive, which I use for "cloud" storage, does not supported the storage API that GrapheneOS' SeedVault supports for backups
Perhaps a newbie question, but since there's a lot of Graphene users here I thought it'd be best to get a human answer.
I have an old Pixel 5 which I stopped using because Google dropped Google Pay (tap to pay) on it. I moved to a new device (Pixel 9) for daily usage but still have the 5 laying around (due to low resale value).
At the time I moved, Pixel 5 was about 1.5 years (November 2023) beyond Android security updates. I still love the form factor (more than the bigger 9 I use now) and it has much more life left in it. I'd quite like to use this as a backup device for basic utility (camera, phone, SMS, basic read-only web use) and to take with me for runs and travelling.
Would installing GrapheneOS on this device likely make it more secure? Do Graphene releases work the same on all devices, or is it sort of device-by-device basis?
Pixel 5 should only be used to preview what GrapheneOS provided prior to October 2024 when Android 15 was released and we migrated to it. It's an end-of-life device and therefore lacks driver and firmware updates. We were able to provide some of those updates past the end-of-life, but not most, and we recommend against using it. We show a notification about it being an insecure device at boot. We continued providing all of our updates and the Android updates for it until the release of Android 15, at which point we shifted to supporting it via a legacy extended support branch based on Android 14 QPR3 with backported AOSP patches and minor fixes of our own. Our support for the Pixel 5 has been winding down further since it's increasingly insecure and we don't want people to use it based on us still providing updates. A Pixel 5 works as a way to try out outdated GrapheneOS but that's about it.
Using GrapheneOS on it would be more secure than the stock OS but it's going to be quite insecure regardless of the OS so we'd recommend just not using it. The intention of our extended support prior to Android 15 and then legacy ex trended support following Android 15 was harm reduction for people unable to afford a new device yet. That's essentially over now. We just didn't remove it from the site yet to avoid complaints. It informs people that it's an insecure device at boot so it's better than people getting misled into believing the alternate OS they've put on it keeps them safe when it doesn't.
Yes it will make it more secure (and faster!), but it is already receiving only bare EOL updates, but will definitely give it some life extension. See: https://grapheneos.org/faq#supported-devices
You won't get the full set of security measures (those require newer Google Tensor chipsets with ARM Memory Tagging Extensions, so Pixel 8 and later), but it's still going to be far more secure than any Android or even iPhone.
Regarding NFC payments, the apps themselves refuse to run on non-vanilla OSes due to spurious security concerns and Google's maneuvers behind the scenes, but there are reports that Curve Pay works, at least in the UK.
I'll give it an install tonight. I'm curious to play around with it anyway and if I make minimal use of it, it should be pretty secure by it's use case.
My personal favorite feature of GrapheneOS is that we can toggle the network access permission.
In the past, I'd have to root my phone just to be able to install a firewall to do the same.
Big props to GrapheneOS!
True privacy is such a rare commodity these days. It’s a breath of fresh forest air to enter an OS unwatched, allowing your mind to be free.
Not to get too deep, but contemporary philosophy posits that our phones have become extensions of our brains (not only theoretically, but literally! See e.g. Andy Clark and David Chalmers, “The Extended Mind,” 1998). Our devices have access to profound parts of our lives— our habits, friends, desires, notes, thoughts… With something this fundamental, it’s vital to have privacy.
Thank you, Graphene team, for all the hard work you do.
The one thing that prevents me from switching my Pixel over is the lack of support for emergency services to see your location if you call the emergency number. I know this because I called twice while having GrapheneOS installed.
I do some watersports and always take my phone with me, so letting emergency services see my location is good for my safety in case I ever got into trouble on the water. I also have a PLB, but I like to have two devices for redundancy, as is best practice.
It sounds like you're in a region not supporting E911 but rather depending on Google's proprietary Emergency Location Service. We plan to make our own implementation of what that provides:
GrapheneOS supports E911 and has our own network location implementation you can enable which gets used by it. Unlike Google's implementation, our network location is based on location position estimation similarly to iOS. Unlike iOS, we'll be providing full offline support for it.
GrapheneOS supports E911. It doesn't have Google's proprietary Emergency Location Services implemented as part of Google Play services which some countries depend on. We plan to implement the same standard it does for regions without support for a variant of E911:
Counter-point: Pixel 9 with GrapheneOS, location services off, Netguard installed and active; I engage with emergency services on a regular basis for work and always receive the public record which tracks the incident. The reported coordinates are almost always within 100' of my actual location, so YMMV.
I have been using GrapheneOS en my pixel for almost a year and quite satisfied.
The docs for compilation are neat so I'm running my own build with my own signatures and my own repository of their AppStore for my third party apps that I also build from source.
I run only those apps on the main profile and then keep a private space (set to autokill on lock) for proprietary apps that require Play Services.
The article mentions the lack of a swipe keyboard, which is an issue for me.
There is an option though: Heliboard with a custom swipe configuration applied (which is apparently sourced from Google, I'm not sure how "grey" that is).
It definitely works as a swipe keyboard, but it's just not as good as GBoard. I will persist, however. I hope that it's learning at least...
I was tempted to use this but when I looked into the team behind it there seemed to be some issues as exposed by Louis Rossman here: https://youtu.be/Dl1x1Dy-ej4.
Instead, I installed CalyxOS and have been using it over a year now and I'm very happy with it. Check it out.
Hi there. GrapheneOS community manager here.
It's a weird video to bring up without any context. Louis Rossmann made that video and leaked private conversations that were had fairly soon after the person in question was repeatedly swatted by someone who has a fan of the person Rossmann was voicing support for.
Unfortunately, Rossmann turned out to be very dishonest, which in retrospect makes sense, seeing as he has no issues with using Kiwi Farms. He's verified account there is named "larossmann". I suggest you look into it.
It's not just something he's done with GrapheneOS and the founder of the project. There are many videos, such as the one he did on Linus from Linus Tech Tips where he similarly misrepresented things and ascribed mental health labels on them.
Regarding CalyxOS, I would recommend people check out https://eylenburg.github.io/android_comparison.htm as a third-party comparison for various projects, including GrapheneOS and CalyxOS. They're not similar projects.
"Never meet your heroes". Also, the opening monologue to Tool's Third Eye[0].
The older I get the more examples I've come across of a person destroying their reputation by either self-over-exposure (social media) or just basic exposure via news of some outrageous or illegal behavior.
I don't have a problem with whatever line you choose to not cross, and I was once much more self-righteous, but I've more recently pretty much made the conscious decision to separate product from producer, art from artist, etc.
Theo Lengyel was recently arrested for murdering his girlfriend, and yet I will still listen to and enjoy Mr. Bungle's music.
Gary Glitter... I still like the song Rock n Roll Part Two.
J.K. Rowling has some controversial views on transsexual women, but that doesn't mean that the Harry Potter series is any less worthwhile reading than it was before.
ReiserFS
I still buy Nestle Quik occasionally
Steve Jobs, Bill Gates, Mark Zuckerberg, name almost any tech bro... (but not Steve Wozniak, he's a treasure)
Sports stars.
Musicians.
I wonder how many other things are worthy of protest if we knew all the facts about all the people who were involved in it's creation.
(I'm attempting to respond to the general concept of "he/she/they bad = it bad", not commenting on GrapheneOS vs CalyxOS or anyone's personal choice over where / what they choose to apply "he/she/they bad = it bad" to, other than saying that it should be a conscious decision not a reflexive reaction)
This a video where he openly bullies someone, live streams their private messages where they're getting upset with him bullying them and repeatedly, blatantly lies about them including falsely claiming they're insane, etc.
Rossman lied about stopping using GrapheneOS and has continued using it after that point.
The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
He has done similar things to others, labeling them as insane and delusional.
> This a video where he openly bullies someone, live streams their private messages where they're getting upset with him bullying them and repeatedly, blatantly lies about them including falsely claiming they're insane, etc.
That is the most disingeneous take on the video.
The claim this kind of commenters that freely carry water for the toxic GOS (ex-?) lead developer is the exact reason why Rossmann made the video.
The evidence is all there for the public to see.
Daniel does not get to essentially harass people he disagrees with after they have been asked to not contact them, threaten them to "publicly expose them" and get away scott free.
Being a genius at cyber security or autistic does not give one a free pass to treat other like garbage.
> The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
The video was made to expose the harassment of the project founder toward Rossmann, when the former contacted him out of the blue with frivolous accusations after they parted way a year earlier due to un-reconciliable disagreements.
> He has done similar things to others, labeling them as insane and delusional.
You are exactly right. To summarise for those who do not want to watch a video, the video shows communications with Graphenes lead developer in which he was extremely hostile and threatened Rossman. It also goes into how said developers hallucinates being attacked by specific other sites, like a Linux YouTube channel that obviously did nothing to him. His goons then attack those projects.
You have to be aware that you give that person root when you use Graphene. All possible technical improvements aside this is a very big risk. He claimed he would step back after the video released, then called that a lie and continued with everything.
Calyx seems to be the best alternative right now without such a risk factor.
I second this opinion, with some additional nuance.
While I don't think the developers necessarily hallucinates being attacked (i.e. given the nature of the project, I would expect them to be persons of interest, be it from surveillance agencies, or even state actors), the main issue with Rossmann is their claim that he is either personally directing harassment against GOS, or colluding with and encouraging other communities to harass (mainly Kiwifarms, Techlore, CalyxOS, and other Android related FOSS projects).
This claim seems to originate then cascade from Rossmann leaving the comment "Informative, but unfortunate" on TechLore's video criticizing GOS's leadership.
This is taken as explicit support of TechLore community's / KiwiFarms alleged harrassement on the lead GOS developer, and this has somehow been cascaded and blown out of proportions, and considered by GOS developers as evidence of Rossmann's wrong doing against them.
As mentioned somewhere else, I am using GrapheneOS since 2 or 3 years now, based on Rossmann recommendations.
The software is very good, pretty much native Android experience, but without the extra alleged Google snooping / root access.
Rossmann himself seemed to have stopped using it as his main device because of fear of retaliation given that the GOS devs could potentially target him. Better safe than sorry.
I still use it because I am not that high profile of a person, and generally will use throwaway when it comes to discussing anything GOS related at this point.
The overall leadership however, based on Rossmann's and later my personal interactions with them however, did leave a bad after taste.
Calyx has lackluster security practices, and even removes signature checking so they can sell microG as Google Play Store to apps. This is an objective statement, graphene OS is leagues ahead of anything on the market in terms of security, while calyx is basically just a custom ROM to tinker with.
As for the personal aspect, the lead developer is definitely not the best representative of the project from a communication perspective as he might not have that kind of social skills (based on his posts). [1]
But he (Micay) is an excellent security researcher, and has an excellent track record when it comes to prioritizing his users. There was a sponsorship in the beginning, where the legal entity, CopperheadOS tried to hijack the whole project. But Micay rather kill the project, than let the users' security suffer and revoked the signing keys. And I'm sure such a betrayal would cause anyone to lose a lot of faith in others' actions.
> Give that person root
Complete bullshit, what root?! And if anything, you are the one who are trying to discredit a project here, by sharing some dumb clickbait video.
[1] I see that there is now a project manager doing most of the communication, which is an excellent solution!
Can you elaborate on why this is a risk factor? What do you mean by saying we're giving him root? If a person is paranoid of being chased i would expect them to put even more effort into the security of the OS he develops, not to add backdoors. But please expand your own reasoning.
There's way much more to it than what you said here.
> extremely hostile and threatened Rossman
At the time, he was very upset. You know, because he was swatted multiple times. Of course he was upset when Rossmann showed his true colors and was trying to talk to him. Rossmann saw this as an opportunity and recorded it as it was happening. He tries to portray Daniel as crazy and people who attack the project and his friends on Kiwi Farms lap that stuff up.
It's not true that he stopped using GrapheneOS, though. He continued using GrapheneOS for months after that video, which you can see by watching his later videos.
> hallucinates
Repeating baseless claims that he's crazy.
> You have to be aware that you give that person root when you use Graphene.
What? This is a very strange way to say it. Either way, it's literally impossible for someone on the GrapheneOS team to target someone like what was claimed in the video. GrapheneOS devices don't send identifiers when they contact the update server. The update servers also only host static files.
> Calyx seems to be the best alternative right now without such a risk factor.
The "risk factor" is completely false. It's all made up to attack GrapheneOS, making the founder look like a crazy person, then people are scared of using the OS. CalyxOS is not a hardened OS and rolls back security in some ways. It's not the next best alternative for people who care about these things.
Does Vanadium include the necessary APIs for uBlock Origin? Otherwise this seems like having a long explanation of how secure the windows are with titanium frames and bulletproof glass while the front door is wide open.
We recently made it so that the call recording option is not hidden away. If there are 7 options, it's RTT that will be the last one now, and we've made the scroll bar always be visible to make it clearer to people that they can scroll there.
> Our community manager has provided a response to the recent LWN article on GrapheneOS with important corrections and context.The article had significant inaccuracies about the history of GrapheneOS, our organization and the details of what we provide.[.................]
As a long time GOS user I just want to remind what a joy it is to see my very old phone outlive flagships due to the lack of bloatware. I upgrade phones just for a single reason: it has been physically hit so hard over the years that it stops being physically functional.
Big thank you to the GrapheneOS team! I have been running it for a week now on my 9pro and the user / app sandboxing is great. If there's a way to donate with cryptocurrency or help contribute, let me know!
You don't need to wipe the phone when updating GrapheneOS. It's as painless as on stock Pixel OS. OTAs downloaded and installed on the background, just reboot the phone after.
Really feel a similar sentiment to a lot of others in the comments! I'm enjoying the recommendations other shared here. I _think_ this follows the rules of conduct for HN but let me know, I recently brained dumped about the following on my blog about the general experience setting up GrapheneOS: https://blog.matthewbrunelle.com/i-picked-a-really-weird-tim...
The submission is a bit old but let me try anyway since I see some user claiming to be Graphene community manager here. Let me first reiterate that GOS is an amazing project and that I am super grateful for your work. That said, I think the #1 missing feature is the lack of a robust backup solution. Las time I checked, there was an ongoing discussion about shipping an ad-hoc backup system for GOS. ANy uodate on this? Thanks!
I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
Has anyone else done the same?
Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
> I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
> Has anyone else done the same?
I did end up going for a Pixel + GOS.
Although it is conterintuitive to use a Google device to get away from Google, according to GOS developers themselves, the Pixel series were the only devices that met their strict requirements for security.
From personal experience, been using it for almost 3 years now, and it gives you 95% of the benefits of Android while giving you back control over your phone, and being generally more secure.
Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
> Although it is conterintuitive to use a Google device to get away from Google
The purpose of GrapheneOS is privacy and security, not specifically avoiding Google, which is not what privacy is about overall. Many companies including Android OEMs have worse privacy practices.
> Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
There are a lot of ongoing attacks on the GrapheneOS project and our team including through fabricated stories and spin. People should look into the actual verifiable facts and look at who is being targeted with harassment and bullying. We defend ourselves from this including debunking inaccurate claims about the project and our team.
Is the camera with GrapheneOS as good as the stock android one? I get to use my wife's iPhone camera sometimes and it frequently shocks me how good and responsive it is. But I'm coming from a OnePlus 8 Pro, which never had a great camera in the first place.
> I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
Fairphones lack proper security patches and OS updates from day one. /e/OS makes this substantially worse compared to Fairphone's own OS. Fairphone tends to lag 1-2 months behind on Android's standard partial security backports and a year or more behind on yearly OS updates. They skip the monthly and quarterly releases. Fairphone 5 uses the Linux 5.4 LTS branch which will be end-of-life in December 2025 with no plan to move away. Older Fairphones use end-of-life kernel branches.
Here's information from the author of the divested projects about /e/OS including data on updates from 2021 up until late 2024:
For the Chromium update summary from July 2024, note 128/135 was shipping each update on a given update path. /e/OS only shipped 12/135. They did not ship most Chromium security updates and skipped most releases. They're still skipping many releases and have significant delays for the ones they do ship.
Here's an article from another privacy/security researcher on /e/OS covering some of these issues:
As documented there, /e/OS has their own invasive services including user tracking in the update client. https://community.e.foundation/t/voice-to-text-feature-using... is another example where /e/OS sends user data to OpenAI without consent for speech-to-text compared to Apple doing it locally by default and Google at least supporting doing it locally and encouraging enabling it.
There's a third party comparison table at https://eylenburg.github.io/android_comparison.htm with a privacy and security focus. It doesn't currently cover invasive services added by operating systems or privacy/security regressions beyond patch delays though. It covers what is done with most of the standard AOSP services and how Google service compatibility is handled.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
The purpose of GrapheneOS is providing a high level of privacy and security. This requires secure hardware/firmware with important hardware-based security features and driver/firmware patches. Using a Fairphone with /e/OS is nearly the direct opposite of GrapheneOS.
> Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
An iPhone would be a far better choice for privacy and security than anything with /e/OS.
What if all this hype about GrapheneOS was actually deliberately invented by the CIA so that everyone who has something to hide would install a beacon with a backdoor on themselves? adjusts tinfoil hat
some things about the UX in this is so bad, which i love because it discourages me from using the phone more. every time i end a phone call i struggle hanging it up. i don't know how to go forward in the browser because the swipe always makes me go back, even when i swipe forward. it's using the ugly material ui components from google. it's great!
all of the privacy and security parts of the UX are good, though.
> some things about the UX in this is so bad, which i love because it discourages me from using the phone more. every time i end a phone call i struggle hanging it up. i don't know how to go forward in the browser because the swipe always makes me go back, even when i swipe forward. it's using the ugly material ui components from google. it's great!
Android has a standard system back navigation gesture based on the previous system back button. Apps integrate support for it. Chromium disables their back/forward gestures when using the modern gesture navigation in the OS. It would have made sense to have a forward gesture but Android never had that as something apps had to implement so it would only work in a small subset of apps and would be generally unavailable, which would be confusing.
Phone app has a button for ending the call. It's our fork of AOSP Dialer with minor changes including UI improvements. Calculator, Clock, Contacts, Gallery, Keyboard, Messaging and Phone are AOSP apps which we need to overhaul or replace. These look and function the same way Google's apps used to but are outdated. They're the open source projects which were abandoned beyond security patches after they forked them off into their own proprietary Google apps. Gallery and Keyboard will likely be replaced while the rest will be overhauled. We know these apps have a bad UI but our focus has been on the core OS instead of apps people can replace. We're beginning to do more work overhauling these.
There are some corrections that we have contacted the author about regarding the history of the project. They initially e-mailed us to ask a few questions but seems to have maybe misunderstood something.
For clarity, GrapheneOS is the continuation of CopperheadOS, not a new project that spun off from it.
As an example, it can be seen that our repositories and legacy bugtrackers are ours:
It's a direct continuation, but was renamed to GrapheneOS post the failed takeover attempt. GrapheneOS has persevered and is all the stronger for it. Over a decade now. :)
That is not correct, or at best a very questionable interpretation. Graphene is a continuation of the open source side of copperhead, but the copperhead project continued to exist even though the Graphene dev sabotaged it by deleting the cryptographic keys. Copperhead is the continuation of copperhead is my reading, Graphene is just also a continuation in a different project.
Why lie about something so easy to disprove by a bit of research? There were a bunch of articles about this back then, even wikipedia states it clearly.
It is insane the amount of "news" about GOS that somehow get things wrong.
It cannot be coincidence but misinformation on purpose.
On Twitter, GOS team have to often reply with the actual correct information, it is insane man.
Reading some comments here regarding hidden profile, security through obscurity doesn't and will never work.
Add to that the fact that GOS is well known now, those people think that if they were forced to give their phone away, they won't have to disclose the hidden profile??? Newbies!!
I don't wonder why GOS team never bothered to prioritise this.
I have been using GOS for a few years now, it is perfect, full control over everything, the teams support is like no other and full transparency about everything, the release notes are like no other.
If it's just for trying out, then go for the cheapest second hand Pixel that's still supported by GrapheneOS and still has a battery that can hold charge for as long as you need it to for testing.
I bought a second hand Pixel 7a for my recent migration. Battery isn't great, but it's good enough to get me through a day.
Battery life improved a lot with the 9th gen Pixels other than the Pixel 9a due to the dramatically more efficient cellular radio. Set it to "4G" or the GrapheneOS added "4G only" as the cellular network mode and you should save a lot of battery life compared to having 5G enabled all the time. Battery life heavily depends on the apps, network and overall configuration. It's easy to end up with bad battery life with lots of apps doing their own push, etc.
GrapheneOS users tend to avoid using Google services when possible and this has a battery life cost when using apps like Signal with their own push systems. In the case of Signal, Molly is a fork with UnifiedPush support that's more efficient but it requires running a server to convert FCM to UnifiedPush since Signal doesn't support it.
GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code. It requires hundreds of binary blobs from the vendor partition of a stock Android ROM, many of which have root access and have not been audited by anyone, including Google, who often lacks source code for them.
Beyond that, the GraheneOS team still controls a single signing keychain for all phones in the wild, which we have to assume is still controlled by Daniel Micay (strcat) as it has not rotated as far as I can tell since he mostly stepped away from public view.
He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness. Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I can't recommend GrapheneOS for any high risk use cases until:
1. they are able to find a device they can run 100% open source code on with no binary blobs
2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly
4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
So you're saying don't use a smartphone at all, which isn't possible, or use CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
> don't use a smartphone at all, which isn't possible
I run a b2b tech company in Silicon Valley and have not carried a smartphone in 5 years or had an LTE subscription in 6. I have a family and hang out with friends, mostly tech workers, at least once a week. I am online when I am at my desk or one of my family PCs, otherwise I am offline. It has been a massive productivity boost, attention span boost, and social improvement in every way.
I don't miss hours of doom scrolling a day and missing out on being present with friends and family. Took a few weeks to rewire my dopamine engine so the FOMO went away.
Phones -are- optional and if you think otherwise you might be an addict.
> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
It is better in one way: a reasonably stable person holds the keys to the kingdom. Personally I do not like having -any- central person controlling my devices, so I just opt out of Android entirely until that situation changes.
I am a supply chain security researcher and founded a Linux distro where no single computer or maintainer is trusted, so trust decentralization, freedom, and control in software are very important to me.
> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
CalyxOS lacks the current driver/firmware patches and isn't a hardened OS with similar privacy and security patches. There are plenty of worse options but people are better off using an iPhone.
Hardware and firmware is closed source in general and the complexity of that dwarfs a few dozen closed source driver libraries used on top of open source kernel drivers. Pixels have those libraries built with debug symbols and they're not hard to review. It's not obfuscated code and you're given the function names, etc.
Those few dozen mostly quite small libraries being open source instead of closed source with debug symbols would be nice and is something we want. With an OEM partnership, we can have access to the sources and build them with hardening even without those being open source yet. We can likely include debug symbols just as Google did for the most part on Snapdragon Pixels. Convincing a company like Qualcomm to open source those would be ideal, but it's far from being at the top of a rational list of privacy and security improvements which could be made.
> This does not make sense at all.
You can see he's once again making a baseless claim that I'm schizophrenic, delusional, etc. in his post here as he has done many times before. There's also the baseless claim that I believe wild conspiracy theories. It's not me making unsubstantiated claims about backdoors and proposing approaches to prevent it which disregard the hardware and firmware to focus on the OS having reproducible builds, which would not stop malicious changes hidden at a source code level. I don't think Hacker News should permit baselessly claiming someone is schizophrenic. It's not reasonable discourse, and neither is linking what's clearly harassment content from a Kiwi Farms as happens here regularly. I've never claimed GrapheneOS prevents hypothetical backdoors and certainly wouldn't claim reproducible builds (which we have) can somehow we used to prevent it for the OS.
We can make more use of the reproducible builds but enforcing anything based on it requires early access and more resources to fix reproducibility issues early to avoid delaying security updates. It will not avoid trust in the OS developers and the projects it uses itself. It can only reduce trust in the build infrastructure and people involved. Open source does not prevent backdoors. The small amount of closed source library code for supporting a modern smartphone SoC, etc. is also quite insignificant compared to the overall hardware and firmware complexity. Reviewing those libraries is also quite doable. Open source is not a hard requirement to review something, particularly with debug builds for most of it and no obfuscation. When we find bugs in this code with MTE, we get nice tracebacks with the function names due to the debug symbols. It's hard for us to make our own fixes for it, but not impossible. We would prefer if they were open source, but it's FAR from the most pressing issue and is something SoC vendors could quickly solve if convinced to do so.
> my best advice today to potentially targeted individuals is don't carry a phone at alil
Lol. I hope you like working with geese, but be careful, they can't be trusted!
Also, you are pretty much factually wrong on a bunch of items on your list. GrapheneOS still has room for improvement of course, but they are very ahead of anything else on every aspect. And where you are not factually wrong, you are just unrealistic. There is no 100% open-source hardware, period. This is complete "what color you want your dragon to be" category.
> Lol. I hope you like working with geese, but be careful, they can't be trusted!
Geese? That is offensive. I raise chickens.
I also run a successful tech company, and have a full EE lab, several full server racks, and more tech in my home than anyone I have ever met.
Phones are completely optional in modern society. We have just convinced ourselves we need them because doom scrolling and constant notifications are addictive.
Print your boarding pass, ask for paper menus, pay with cash, and arrange times and places to meet people and then actually be there on time. The rare times you really need to do online work on the go, bring an actual computer with a real keyboard. Free wifi is everywhere.
Works just fine, and as a bonus your time away from home becomes mostly invisible to marketing firms.
> Also, you are pretty much factually wrong on a bunch of items on your list.
If you are going to call me misinformed, please take the time to prove it so I can stop sharing information I otherwise have no reason to believe is incorrect.
> There is no 100% open-source hardware, period.
Multiple fully or mostly open hardware computers exist. They just cannot run android.
MNT Reform, Precursor, and Talos II are the top three that come to mind.
Those are lightyears ahead in openess and auditability compared to anything Google produces.
> GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code.
It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.
Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.
> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.
There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.
> Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.
> 1. they are able to find a device they can run 100% open source code on with no binary blobs
There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.
A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.
> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.
> 3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly
> 4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.
AOSP having a regression causing a timestamp to be added somewhere isn't a reasonable justification for blocking security updates. No system without the ability to investigate the cause and determine if it's okay would be reasonable. We would need to finally have early access to new Android releases to test this in advance and have fixes ready to go prior to the stable releases. We do not currently have this early access but will likely obtain it from the OEM we're working with soon. We would still need additional resources to have ongoing testing for this and fixes for any relevant regression that finds. Porting to new releases prior to them being stable and specifically testing this would be needed.
We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue.
In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works?
If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources?
> Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible.
> Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design?
> If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it.
He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.
Graphene is a fantastic operating system for Pixel devices. Simple, reliable and with plenty of security and privacy features to make you feel warm and fuzzy. System updates are automatic, actual phone functionality is flawless, perhaps the only complaint to be had is the quality of camera, which probably lacks proprietary drivers. Signal works fairly well - even without abusive Google Services installed, making this a perfect daily mobile driver. Much gratitude to the developers of this project.
GrapheneOS does not degrade the camera quality at all. The quality will depend on the app being used. If you use Pixel Camera on GrapheneOS, you'd be getting the experience you'd get on stock OS using that same app. Similar for our built-in camera app.
While a big proponent of this, to my mind, it seems a bit counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks, creates a bad patch and empties my bank account.
It's important to note that GrapheneOS is not some niche barely-used project. It has existed since 2014 and is used by multiple hundreds of thousands of people at this point. There are also many eyes on the project through people forking it to make their own products, people maintaining their own builds etc. GrapheneOS is also reproducible in addition being open source.
On our side, we are very particular about accepting outside contributions if they don't need meet our standards, and code is heavily reviewed within our team before being merged.
All in all, your concern, while valid, isn't something that's likely to happen precisely because we're very aware of situations where it has (see xz) and are therefore very vigilant. The kind of thing you're worried about isn't likely to come from a big project like GrapheneOS that has many eyes on it, but rather something small that's used everywhere and barely has a couple of devs working on it, if that (again, see xz).
> it seems a bit counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks, creates a bad patch and empties my bank account
From what I have observed, nobody is held to account when there is a software issue, commercial or open source.
>counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks
Open source software is everywhere. Do you think Microsoft or Redhat going to be held to account if they accidentally added some backdoored OSS code? Moreover all of the development happens in the open and you can build it yourself. I'm not sure what the alternative is. Just trust Apple has their shit together with iOS?
Google also cannot be held to account, its legal team out resources countries and if you attempt to litigate at best they will just keep you busy until you're bankrupt.
At least graphene wouldn't be expected to shield the perpetrator.
You say the same thing about Linux? This feels like old open source FUD, the only case I know of off hand is the xz util backdoor and that was found and patched before the malicious patch had made it into the main distribution channels.
This take demonstrates most people's inability to rationally threat-model: you would rather trust a known-abusive authority than an unknown-good samaritan, because of a false notion your bank balance is actually significant enough to warrant such an attack.
I just installed Graphene on a new pixel. I've only used it for two days, but I got that same feeling of "finding buried treasure in your backyard" I got when I first installed Linux in 1999. I can't believe this amazing software is free in all senses of the word. It is a TON of work and they got so much right. The security and usability settings give all the grainular control I've known was possible and wanted for a long time.
I see some core team on this thread, so just wanted to say THANK YOU! Awesome job! Keep fighting for the users!
I'm totally the wrong person to offer recommendations on mobile, but so far it works very well for me, but then, I use almost no third party apps, and none of them are Play store only. My only complaint is the hardware (outside of their control).
I got it installed last weekend, really powerful mobile OS.
I did do about three weeks of research, as I worried that maybe a number of apps wouldn't run on it or needed some form of deep attestation. Didn't find much, OpsGenie and other work apps are happy with the GOS level of attestation provided.
Great to have Google kicked off the phone. So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
One tip from me, if you came from stock Pixel: You can download the default Pixel sounds and set them up like it was. Have a look for "Your New Adventure" online, the message sound is "Eureka".
I've got a Pixel 9a expected to arrive today, specifically for it to run GrapheneOS. One of my old phones was a Nexus 6P running CopperheadOS (prior to the dispute that spawned GrapheneOS), and it was great back then. Looking forward to how things have progressed in the years since.
I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.
2 replies →
"Great to have Google kicked off the phone"
Except the default browser is Chromium with some changes
This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that
Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else
It even offers a sandboxed Google Play Store
It tries to copy Google paternalism
It swaps a Google mothership for a Graphene mothership
What if the computer owner does not want a mothership
Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access
If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
Most apps but not all will try to connect to the internet at some point, even if you never use them
The user-hostile design of Android is that apps keep running in the background after they are "closed"
(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)
Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.
One does not even need Netguard to see this subversive activity
Try this at home
Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD
Put the phone on the same network as this computer
Set the phone's gateway address to the address of the computer
Run tcpdump on the computer and filter for the phone's IP address
11 replies →
> So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
For those of us who aren't ready to cut the umbilical cord to the mothership, you can also root/firewall on normal android to stop this. In fact I choose to not be able to use banking apps in order to cut out the crappy ads.
16 replies →
> I can't believe this amazing software is free in all senses of the word.
I wish that were true, but if you delete the 100s of binary blobs (many with effectively root access) copied from a stock donor vendor partition the phone won't function at all.
There is no such thing as a fully open source and user controlled Android device today.
It's not all grim. GrapheneOS utilizes IOMMU to isolate the baseband and sandbox the wireless components. Even with binary blobs, the wireless radios cannot read encrypted traffic.
https://grapheneos.org/faq#baseband-isolation
Sure, it's not perfect, but it's still really, really good. Even with the binary blobs that are on it, Graphene phones have been impossible to unlock via commercial cracking tools since 2022.
https://osservatorionessuno.org/blog/2025/03/a-deep-dive-int...
1 reply →
Let's not allow the perfect to be the enemy of the good. GrapheneOS does what it can to isolate those things as much as possible. It even makes good use of hardware features such as the IOMMU. It's a huge improvement on the status quo, even though it's not going to pass FSF RYF certification.
2 replies →
Was there ever? And is the situation improving or worsening?
I am alright with things that allow for improvement, at least in theory
16 replies →
Laptops, desktops, smartphones or tablets are closed source hardware with closed source firmware in general. There are products marketed as if they're open source devices which are in fact closed source hardware with almost entirely closed source firmware. The software on top being open source is frequently misrepresented as the device itself being open source, which isn't the case. Not shipping important firmware updates in the OS provides assurance of insecurity while not changing the fact that the hardware and firmware is closed source. It has to do with a loophole defined in a certain ideology around software, not open hardware or privacy/security.
5 replies →
As opposed to using what, hand gestures? There is simply no production ready hardware with non-proprietary software at all.
4 replies →
This is also the case with mainline linux though. Good luck using Nvidia graphics with only FOSS components.
Even more FOSS friendly graphics vendors like AMD and Intel rely on binary firmware.
10 replies →
[dead]
I think they don’t even have basic location mocking. They have disable or enable. But some apps won’t work.
Mock Location is a standard Android feature available in GrapheneOS. Our upcoming Location Scopes feature is being added for per-app control rather than global.
It's fairly pointless for apps to check for Mock Location being active without also verifying the OS via the Play Integrity API or hardware attestation API. Most apps checking for it are using or in the process of adopting the Play Integrity API. Apps enforcing the Play Integrity API basic/strong integrity level won't work on GrapheneOS unless they explicitly allow it. A growing number of apps doing this are explicitly allowing GrapheneOS. It would be counterproductive if our Location Scopes API didn't provide a way for apps to check if since those apps simply wouldn't permit GrapheneOS. However, it doesn't need to be the existing Mock Location API. It can be our own API which would only be used by apps explicitly choosing to permit GrapheneOS. This would allow apps like Pokemon Go and Ingress to permit GrapheneOS even if they insist on not allowing directly spoofing location.
I believe this is in the works: https://bsky.app/profile/grapheneos.org/post/3lqbhoqwrjs2y
My understanding is that Mock Location on android is a developer setting that apps can easily check for, and as such, is basically useless (it will not fool any app that is asking for your location).
It's basically only useful for debugging.
Not by default, but there are several apps on F-Droid that do this
2 replies →
Where do you get the apps from? Google's App Store?
Obtanium[1], F-Droid[2], Aurora Store[3] and FFUpdater[4] are some options. Signal self updates from the APK download[6].
I recommend putting proprietary Play Store apps grabbed with Aurora Store in the work profile with Shelter[5].
[1] https://obtainium.imranr.dev/
[2] https://f-droid.org/
[3] https://f-droid.org/packages/com.aurora.store/
[4] https://f-droid.org/packages/de.marmaro.krt.ffupdater/
[5] https://f-droid.org/packages/net.typeblog.shelter/
[6] https://signal.org/android/apk/
15 replies →
Aurora Store on F-Droid is a FOSS frontend for the Google Play Store that is a seamless drop-in. Requires no Play Services, nor an account.
10 replies →
F-Droid app store. https://f-droid.org
do you need to access your mobile for bank accounts ? does that work ?
Someone's keeping a list of banking apps known to currently work with GrapheneOS: https://privsec.dev/posts/android/banking-applications-compa...
Check if yours is on the list.
I hate that many banking apps refuse to run on non-Google OSes. I can see that my banking app doesn't even work on GrapheneOS based on the link given in a sibling comment. It makes absolutely no sense from a security perspective since I am still able to log in using the browser, and the web app has the exact same UI and authorization flows as the actual app.
It all seems like a security theater with the consequence that, ooops, we just vendor locked in all our customers to run a less secure OS by a company whose business it is to collect personal data and show ads that people don't want to see.
4 replies →
I'm always afraid of my phone getting stolen or losing it somewhere so I have a completely separate iPhone, which runs my banking apps. I keep that phone at home.
11 replies →
It depends what banking apps you use. Some are available. From my observation major banks in Poland work just fine. You can pay via NFC using the mBank app if you need to. Revolut also works fine. gPay just doesn't work however therefore you cannot pay with this via NFC. I use my Garmin watch to pay for all things in physical stores anyway, so no need for NFC payments anyway.
1 reply →
In Sweden all the banking apps I've tried works, including BankID.
2 replies →
Have a second profile with fewer restrictions for those apps you think you need but don't want to compromise security for. My second profile has one app, which is my banking app with all the dependencies it rudely requires for functionality
I have a rooted Graphene on a Pixel 9, and the only bank which isn't working is Revolut.
2 replies →
As a single datapoint, revolut does not work unfortunately, so I moved back to the default pixel OS.
9 replies →
[dead]
https://grapheneos.org/donate
If you want it to stay free
have you used something like lineageOS before?
I agree. I love using Graphene OS. Came for the security, stayed for the lack of bullshit.
GrapheneOS? On a Pixel? You must be one of those criminals /s
Arrest this individual
Happy long term user, great project. Here is a list of Open Source Apps, I use to replace Google stuff:
I wish I had this list from the start... Hope it helps someone :-)
Worth mentioning that Fossify also has an amazing Contacts and Calendar app (using both right now on Android 15).
https://www.fossify.org/apps/
Fossify is a FOSS project with a handful of volunteers and they do take donations:
https://www.fossify.org/donate/
> Organic Maps - Open Source navigation (not as good as proprietary ones though)
Note that a community fork done by some core contributors was just spawned: CoMaps [1]
> K9 Mail / FairMail - Mail client
And now there's Thunderbird, which is branded version of K9 Mail IIUC (I don't know if there's any reason to switch from K9 Mail to Thunderbird for existing users)
[1] https://f-droid.org/en/packages/app.comaps.fdroid/
Does the fork solve the issue with inputting addresses? Organic Maps will happily route to the correct street, but falls over when entering a standard format address (i.e. XXX Streetname Ave)
1 reply →
Can also recommend:
Aegis: TOTP 2FA code manager
SuperCards: stores shop loyalty card barcodes
KeePassDX: password manager
ReadEra: eBook reader
Magic Earth: another maps app
Vivaldi: power-user's browser
JuiceSSH: SSH client
Termux: like running a Linux term
AntennaPod: podcasts
I do not use Aegis anymore, I use KeePassDX instead. It works for TOTP just fine.
JuiceSSH is still under development?
4 replies →
>Magic Earth: another maps app
>Vivaldi: power-user's browser
Propietary. Get Fennec with FDroid with Ublock Origin and some addons.
1 reply →
CoMaps: another maps app
StreetComplete: help update CoMaps and OpenStreetMap
Catima: for loyalty cards
I'm surprised no one mentioned NewPipe, the best YouTube App. A few other apps I use Feeder - RSS App Fedilab - For Mastodon
I prefer Tubular which is a NewPipe fork with not only an ad blocker, but also with SponsorBlock and ReturnYouTubeDislike.
1 reply →
How do push notifications and similar things work on GraphenOS? Do they work reliably out of the box on most apps, or did you have to set up MicroG/whatever GrapheneOS's equivalent is?
> How do push notifications and similar things work on GraphenOS?
Some apps require Google's FCM for push notifications. You need to install Sandboxed Google Play services from the GrapheneOS App Store and grant them unrestricted battery access (so they can run in the background, which is required for maintaining a network connection to FCM and delivering notifications). https://grapheneos.org/faq#notifications
Other apps like Signal use their own background connections, for example WebSockets, to deliver push notifications, but keeping a connection open for each app consumes more battery life than just having one background network connection. Also, not every app supports this.
For Signal specifically, the GrapheneOS project recommends either using FCM via Sandboxed Google Play, or installing Molly (https://molly.im/), a fork of the Signal client for Android, which makes some changes to reduce battery consumption when using WebSocket-based notifications. It also allows you to use UnifiedPush (https://unifiedpush.org/) for notifications instead, but that requires an application called mollysocket (https://github.com/mollyim/mollysocket) running on a server.
1 reply →
Push notifications work on GrapheneOS whether apps do it themselves, use UnifiedPush with the user's choice of provider or use FCM. UnifiedPush and FCM are a more efficient design where apps share a push connection. Unfortunately, many apps only support FCM and some support their own push as a fallback, but few support UnifiedPush. FCM works very well via sandboxed Google Play, which is an approach where Google apps can be installed as regular sandboxed apps with zero special access or privileges. Nothing FCM does actually requires special privileges and our compatibility layer makes it work without it.
GrapheneOS does not include sandboxed Google Play but rather includes an open source compatibility layer providing support for installing Google Play as regular sandboxed apps. They can't do or access anything more than other apps including the Google Play code running inside apps using Google Play which is the reason for choosing this design. It simply uses the same app sandbox and permission model which are both greatly improved by GrapheneOS for supporting running the rest of Google Play not bundled with apps using it.
Worth noting apps don't need Google Play services to use Google services and many Google libraries like Ads and Analytics work without it. FCM requires Google Play services but many of their libraries do. There are Lite variants of Ads and Analytics for keeping apps smaller which lose the ability work without Google Play services. The general reason for the design is they don't want to have huge apps and want to be able to update the clients for their services without app developers doing it and shipping an app update. FCM is one of the special cases requiring the central design for efficiency. UnifiedPush is an alternative with choice of implementation / provider.
Everything works out of the box, and it doesn't use a third party layer like MicroG. The difference is that Google's apps/services are not given admin privileges like they usually are, so you can selectively enable or disable things.
For example, installing an app on Google Play works like F-Droid. Once the download finishes, you have to open the Play store app to trigger a system dialog to accept the installation. On other Android devices, GPlay can install apps without your approval.
NextCloud - sync photos, calendar, notes and contacts to your own server.
Does the NextCloud app now sync contacts and calendar? Last time I tried, years ago, it did not. I use DAVx5 to sync my NextCloud contacts and calendar, via CardDav and CalDav.
1 reply →
for someone who doesn't want to replace Google services, does it still make sense to move to Graphene?
Absolutely. You can basically get almost the same experience as you would on a stock OS device, but with much better privacy. On the stock OS, Google apps get privileged access, so they can still access photos and your camera and all that, but what people don't realize is that their privileged access also includes things like usage data, hardware identifiers, etc. Using Google apps on GrapheneOS makes a lot of sense.
The only problems you might run into would be some features might require privileged access, things like Now Playing. Makes sense because normal apps cannot have unrestricted access to the microphone like that. Google Wallet works, but you cannot make payments because the app refuses to work on alternate OSes.
Besides that kind of stuff, though, I've used all sorts of Google apps without issues.
1 reply →
Over the years, Big Tech has given me reasons to trust them less and less. So I encourage you to be a rebel: cut Google out and live outside the system.
Last I heard, Google discontinued publishing device trees and driver binaries for Pixel devices with their recent changes to their stewardship of the AOSP [0]. Was it something definitive or are they merely delayed? If the practice is being discontinued, what would be the reason why? Doesn't publishing these artifacts create a business case for customer demand for the Pixel devices? Or is there some cost that outweighs the benefits? Is it maintainer overhead?
I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!
[0]: https://news.ycombinator.com/item?id=44259921
Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. A few OEMs publish more basic device trees for older Android versions. This was Pixels losing one of their advantages compared to non-Pixels but it was never one of our hardware requirements, which are listed at https://grapheneos.org/faq#future-devices. It isn't part of why Pixels are the only devices meeting our requirements. We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.
GrapheneOS typically ports to new yearly Android releases in a couple days and tends to have it reach the Stable channel in under 2 weeks. We completed our initial port to Android 16 in a similar time period after the release on 2025-06-10. However, we then had to reimplement device support in a similar way to how we would support a non-Pixel device. Our initial production release based on Android 16 was published on June 30th. As usual, we had to spend around a week making a series of releases fixing regressions reported by users. It reached our Stable channel on July 8th.
Since our port to Android 16 took significantly longer than usual, we backported most of the Android 16 firmware, all of the kernel drivers and parts of the userspace device support to our now obsolete Android 15 QPR2 branch and did a few more releases based on Android 15 QPR2 where we were able to provide the full 2025-06-05 patch level which also turned out to be the full 2025-07-05 patch level due to no vulnerability fixes in the July 2025 Android Security Bulletin or Pixel Update Bulletin. This was an unusual approach and not generally a reasonable way of doing things. We were able to do it successfully.
It won't be nearly as much of an issue going forward since we dealt with building the new automation we needed. Our port to Android 16 QPR1, Android 16 QPR2, Android 16 QPR3, Android 17, etc. shouldn't be nearly as difficult and we should get back to our typical porting time for major releases.
> We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.
Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference https://news.ycombinator.com/item?id=44586723)
12 replies →
Quite a lot of detail on this comment, thanks for that!
But I'm still left a bit confused about the future devices GraphaneOS will support:
Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?
You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?
Thanks again!
4 replies →
As you're working with the OEM, I hope you'll consider a model which will come with either an IPS screen or is compatible with a 3rd party IPS replacement.
I bought a Pixel 9 Pro Xl specifically to use with GrapheneOS. Unfortunately, its OLED and my eyes were incompatible. The PWM on the screen was terrible and I had to return it after some headaches.
Of course, none of that was the fault of GrapheneOS. I absolutely loved using it and think your project is vital.
3 replies →
I suppose this means that supporting future Pixel devices will be more difficult? If someone has the ear of anyone at Google, especially someone who works with Android, please share this cause with them!
2 replies →
Is it now possible to build a custom release of graphene for any of my non-Pixel devices or will that, again, bring graphene ninjas to my abode?
I am so excited about the thought of a GrapheneOS native phone!
I heard unsubstantiated rumors that it was somehow antitrust-related. If they are selling off their device business (again), then it makes sense that the device drivers would not be part of AOSP...
> If they are selling off their device business
Android and Chrome are potentially going to be split from Google:
https://www.nytimes.com/2024/11/20/technology/google-search-... (https://archive.ph/egRL4)
Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.
It may be permanent and I think this was the official indirect response:
"AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0]
Emphasis on independent of any particular hardware.
Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]).
[0]: https://www.androidauthority.com/google-not-killing-aosp-356...
[1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-will-...
The main missing feature is password under duress that would open a different “user”. So even if you’re forced to give away your password they won’t get to the real account (some hidden profile or similar).
At least hidden profiles would be good enough for basic protection.
They have this which wipes your device, but you can get killed under duress. https://discuss.grapheneos.org/d/14722-using-duress-password...
GrapheneOS community manager here. The problem with something like this is that it cannot be reasonably hidden when it would be exposed by someone using basic tools. Our Duress PIN/Password feature doesn't make any attempts to mask itself, precisely because we think doing that only gives people a false sense of security.
We think there's a good chance a motivated adversary is going to be familiar with GrapheneOS and its features, and the more mainstream it becomes, the more this can mean "your abusive significant other" rather than someone at the border.
The moment people know this feature exists, it can become dangerous even if you don't use it. You can be threatened to unlock, and even if you do, the adversary can choose to not believe you since they can think you're just hiding it. That puts you in a dangerous situation where they think you can provide something that's literally not there.
It's a very difficult problem to solve, and we don't think that proposal can solve it.
I hate to say this but I don't foresee Graphene being "mainstream". Most users will stick to the stock ROM. The most "mainstream" custom ROM Lineage is only installed on 0.04% of Android devices as of 2023 [1]. Even if Graphene appears in some mainstream news, I highly doubt any ordinary person can recognize it when they see one.
If the threat model is hiding from random people, I think a hidden profile works very well.
Now let's talk about motivated adversary as you put it. Hidden profile and wiping are not either-or, they can coexist. If one is really targeted by a motivated adversary, it should be apparent in most cases, and the targeted person can choose to enter the wiping PIN instead of the secondary profile PIN.
Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
[1] https://9to5google.com/2023/11/20/lineageos-number-of-device...
8 replies →
Tbh I’d say 99% of the criminals won’t know about this.
Let’s say someone have you at gunpoint, you can just give your mains profile pass.
If they don’t even know there is a secret profile you’re good to go.
You’re right, they might assume you’re hiding, but I’d say 99% won’t know what’s even graphene and from those who know I’d say they might force you and you can have 3 sets of bank accounts:
Main profile: 100 Secondary: 1000 Terriary: $$$
Also if you hide all traces of grapheneos would be safer too. Nobody even knows is graphene, so they can’t even check what features you have. Again we are talking about 99% of the criminals, not the tech savvy 1%.
I’d prefer plausible deniability like Vera crypt than what we have now.
3 replies →
There are certain threat/risk models where having multiple profiles might be helpful (non-forensic examination by an offical at a securtiy screening kinda scenario). But you're right, it's nuanced, requires know-how by the user, and possibly a foot-gun for some caught unawares. NOT an easy problem to solve. Personally, as a user, I'd like the ability to be able to choose that option in the instances where I needed it, but it's likey a TON of work for a very small actual user community who needs it.
I think this feature nowadays would be mostly for the border control checks, especially in the US. Basically to avoid being sent back over a JD Vance meme found at a glance, as opposed to actually being held hostage.
I remember a conversation with a political activist refugee. They were in a group of people who got checked at the border, and were asked to unlock their laptops. The border security personnel then proceeded to do a short inspection of the visible systems. They all used Veracrypt's Hidden Operating System functionality, and while it would be trivially detectable, the border security did not, so they got through without problems. If they had refused to "unlock", or used a duress passphrase that wiped the system without presenting a dummy version, they would have been held, possibly for a very long time, and definitely not allowed to exit.
Moral of the story: Different contexts allow for different solutions. It is a sign of false privilege to make assumptions, and not let the user decide. An argument can be made in terms of priority of implementation, but not in terms of "pointlessness". The often used argument of "false security" can be addressed by warnings; yes, some people may not understand the implications, but you do not need to make their own (bad/good) choices for them; that's paternalism, not care.
In the real world, where thanks to my political work I am in contact with many people who had to endure real-world security checks, police raids, investigations, and so on, in all the cases no proper (imaginary) forensic analysis was performed. People make mistakes and remain uneducated -- on both sides. The "But NSA!" argument brought forward typically by white techbros kills a lot of useful technology before it even exists, which is unfortunate for those that would actually benefit from it, and when asked would tell you so. It's also not either/or in reality: In many situations, it will buy you time (while e.g. your lawyer may try to get you and your devices out of the situation), and even if they find out you were trying to fool them, they may give you another chance, and then you can still opt for the wipe code. It makes a huge psychological difference to have multiple options and feel in control.
1 reply →
[dead]
I've seen this be requested for years from various mod users. Is it too difficult to implement or something?
They say a hidden profile is not secure enough so not worth implementing.
I rather have this hidden profile that would stop 99% of criminals than what they have now.
I think their approach to this project is to deliver real security at the cost of features.
This hyperbole is extreme, and unnecessary. If your life depends on the ability to simulate a fake user on a phone, there are more significant problems than a lack of operating system features, and a general failure to defend in depth.
This is a fully general argument against any single thing your life might depend on: seat belts, defibrillators, bulletproof vests, etc.
If the only thing protecting you from getting shot to death is a bulletproof vest, clearly a lot has already gone very wrong, and you're likely to die today anyway. But that kind of thinking is exactly what leads to a failure to defend in depth.
GrapheneOS Discussion Forum: "This site is best viewed in a modern browser with JavaScript enabled. " Security my ass ... To "GrapheneOS community manager" - please fix this. Where is .onion site?
Security doesn't mean you have to go feed the cows and leave behind everything.
In fact, a core aspect of security is having access to a feature in the very first place.
A forum, being hosted on the web has absolutely no reason to stay away from the de facto scripting language of the platform. What would be your threat model for that forum? A zero day that would break the whole world?
It is possible to view the forum without JavaScript being enabled, but not sign in and post. We use Flarum for our forum, and that's a limitation of the platform.
We use Flarum as our forum software for https://discuss.grapheneos.org/. Flarum supports viewing all of the content without JavaScript via an HTML fallback mode using pagination. Flarum simply informs people they'll have a better experience with JavaScript enabled.
Join usenet: https://www.eternal-september.org
Subscribe to comp.mobile.android. Sadly there's no libre client yet, but Mozilla might release a Thunderbird version with NNTP support.
You can read it just fine with Javascript disabled, though.
It's Discourse.
1 reply →
I have used LineageOS [0] for a few years on my old phone, and last year I got a Pixel 4 and I am using Graphene on it. Both systems work well and I am really glad they exist; Graphene gets extra points for its extremely easy installation process. Unfortunately it seems Graphene is already phasing out support for the Pixel 4 [1], so I'll have to switch back to Lineage at some point.
The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
[0] https://lineageos.org/
[1] https://grapheneos.org/faq#supported-devices
>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
Pixel 8 works amazingly with Graphene's new network location feature. Position fixes are SO MUCH FASTER. It is truly a gamechanger. First it was Wi-Fi only, but they just released cellular location as well. They provide a proxy to Apple's location services.
>>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost
> Graphene's new network location feature
I believe it uses https://beacondb.net/, which is starting to have fairly decent coverage, at least in large parts of Europe. You can contribute to BeaconDB even if you have an ordinary Google phone by installing https://github.com/mjaakko/NeoStumbler.
I use LineageOS myself (because Graphene no longer supports my Pixel 5), and unfortunately it doesn't do network location out of the box. You can get network location on LineageOS by installing MicroG, but it's currently somewhat flaky.
4 replies →
My only problem with Graphene is the ridiculous low number of supported devices, i know I know, security reasons and so on. But I would accept an lower security hardened version but at least have Graphene instead of Google's junk
GrapheneOS community manager here. Google's devices are currently the only ones that meet our requirements (https://grapheneos.org/faq#future-devices).
However, we're currently working with another OEM and are hoping to have a device of theirs meet our requirements that can be launched in 2026 or 2027. Nothing set in stone, but we're optimistic thus far.
Extremely happy GrapheneOS user here. Thank you so much for the work you and your colleagues do. Speaking for myself, the adoption of a mobile communication and computing choice that both put me in control of what information I interact with and respects my agency enough to present me with the hard choices about what I do and don't want for myself has been a life-altering upgrade in something midway between "peace of mind" and "outright mental health".
Much like you don't hear the sound of a busy city until you go somewhere truly quiet, you don't remember owning your own brain until you evict all of the entities who have been living rent free in it.
Keep doing the great work you're doing: it's making people's lives better in dramatically more significant ways than most software.
3 replies →
I can understand the GOS' rationale in choosing only the most secure phones. However, I'm more concerned about privacy, and not so much about security. It'd be great to have something like a "GOS-Lite" which accepts some security compromises in order to bring privacy to more people. (And yes, I understand that lower security means less privacy from targeted attacks but even GOS depends on OEM blobs, right?)
If it's a repairable phone like the Fairphone, that would be fantastic. Otherwise, I'm already very satisfied with what you offer. Thanks for you work.
7 replies →
I'm working my way down your requirements.
> Hardware memory tagging
I had to Google this. Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag? Or are you only interested in the memory safety benefits? Regardless, why target requirements that even most desktop computers don't meet?
3 replies →
I really hope it's the Nothing Phone you're talking to.
About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.
1 reply →
This is great to hear. I hope the ORM has a budget model graphene can run on.
that is great but i hope it is not a small run with a 200+ price as happens with the various linux phones.
What's ridiculous about it ? There are now 4-5 gens of Pixels with their major/minor bumps too (A series, pro, etc.). There's enough variety at different price points for everyone there.
4-5 versions of the same phone in the gigantic sea of possible devices
9 replies →
https://calyxos.org/ does a few other devices, seems aimed strait at true privacy
GrapheneOS community manager here.
I would recommend checking out https://eylenburg.github.io/android_comparison.htm for a third-party comparison of these projects. They're not really similar.
CalyxOS downgrades security compared to the Android Open Source Project, often falls significantly behind on standard Android privacy and security patches as is the case right now (they still haven't ported to Android 16 which is required to have the latest patches) and doesn't provide similar privacy or security features.
Features like Contact Scopes, Storage Scopes and our Sensors permission toggle are some of the privacy features includes in GrapheneOS.
Privacy necessitates security. The security provided by GrapheneOS is in order to be able to protect privacy.
7 replies →
Sounds like google is going hostile to the project, so if enough of us miss it i guess we will have to work on new hardware support
GrapheneOS community manager here. Google did make it harder to support Pixels, but we're still doing it and plan to continue supporting new Pixels provided they keep meeting our requirements.
At the same time, we're in communication with an OEM to have some of their devices have official GrapheneOS support, so we're moving towards redundancy.
I actually like Graphene's focus in Pixel. It is available in a lot of countries unlike Fairphone - via Pixel of course.
So Graphene is actually not limited to the developed/western world. As for not supporting other devices, I believe the reason could be the team size and the fact that the fragmented Android world is known for unique shenanigans of every OEM. Besides Google's update/upgrade cycle is another reason it is an appropriate choice.
por que no los dos?
9 replies →
The maintenance burden would be wayyy higher and the satisfaction with the project would plummet.
It's a catch 22. Support other devices, the software won't work as well or reliably or maybe buggy - users get pissed off.
Spent the time to make it not buggy on other devices = now you're doing mor dev work than even Google.
The most fun feature of GrapheneOS is the ability to look at the logs of any app at any time from the App Info page.
wow I had no idea that feature was even there. Thanks for the heads up :)
It's a shame that Android as a whole is trending towards hardware remote attestation. It's pretty much guaranteed that app developers will eventually start writing their apps so that they refuse to run on anything that doesn't pass Google Play Integrity. Being unable to run WhatsApp or bank apps on GrapheneOS will render it useless as a smartphone operating system. It might not be happening right now but the threat of it looms eternal. My bank could flip a switch somewhere and suddenly my phone becomes useless for the purpose of accessing my bank account.
The Google Pixel requirement also makes me sad. I understand that they have solid reasons why. The problem is Google is incapable of selling their phones worldwide. It's really embarrassing for Google and unfortunate for me.
Hardware attestation and Google Play Integrity are two different things, and the former solves the monopolistic practices of the latter.
Not at all. They are one and the same. Both of those things will literally destroy the computer freedom we enjoy today.
GrapheneOS can attest to the device's security. The question is whether the app developers will trust such an attestation. Will they put money, time and effort into evaluating and trusting GrapheneOS? Of course not. They will just decide to trust nobody except Google and Apple.
This is the future. We'll be discriminated against. Can't even log into an account from an "unauthorized device". Their servers will just refuse to talk to our phones if they can't cryptographically verify that we have not "tampered with" them. We'll be refused service straight up unless our computers are straight up owned by corporations.
This so called "integrity checking" is meant to protect the corporations from us, not the other way around. It's so we can't do things like hack our way around their "policies".
2 replies →
I think Graphene gets posted here yearly. Having tested a variety of ROMs dedicated to different elements of security, I can attest that Graphene allows the most "normal" phone usage compared to many others. The biggest factor is the sandboxed Google Play Services, which allow you to use a lot of apps that you wouldn't be able to otherwise.
I've used Lineage without MicroG, as a comparison, and that's becoming more-and-more unusable every day some lousy Android developer tethers their company's app to some feature exclusive to Play Services.
yeah but lineageos with μg is quite good.
unfortunately it doesn't support google pay, which is a dealbreaker for me
Google Pay is not available on any alternative OS due to Google blocking it. It's unfortunately their choice, rather than a lack of support on our end.
Depending on where you are in the world, there might be other NFC payment options for you.
In the EEA and UK, Curve pay works. Paypal made their own solution and is rolling it out, starting with Germany. Both work with GrapheneOS. Many banks also have their own solutions.
Phone-wallet case.
It's interesting that the only devices complying with the security requirements are Google's.
I wonder if Google actually has an internal version of Android that's more security-focussed. Given that critical engineers' personal devices being hacked should be a security threat that's on Google's radar, it's possible.
According to the developers, beside the AOSP software itself, there seems to also be hardware requirements that only the Pixel satisfies.
https://grapheneos.org/faq#future-devices
As a large company, they are probably targeted through their devices and since they have the means, it does make sense that the Pixel devices have high security standards compared to other OEMs.
Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. There are a small subset of other devices with at least nearly all of the security features we require. However, those devices either don't allow using another OS or cripple security for it. There's no other device providing the listed security features and allowing us to support it. Pixels are also the only devices properly keeping up with current Android OS and security updates. We need ongoing firmware and driver updates. There are other devices offering support for a similar time period, but not actually providing close to the same thing during that time period.
Most OEMs do the bare minimum for security. The security features they provide are the ones provided for them by AOSP, the SoC vendor, etc. They provide delayed and quite incomplete security patches.
Android downplays the fact that it has OS releases every month. There's a new monthly, quarterly or yearly release each month. The monthly Android Security Bulletin patches are a separate thing providing backports of a subset of the security patches (most High and Critical severity AOSP patches) to older initial yearly releases (the initial releases of Android 13, 14, 15 and 16). There are also a huge amount of SoC and other hardware-related security patches with a small subset included in the Android Security Bulletin. Most OEMs struggle to provide these backports and vendor patches on time for a reasonable time period. Non-Pixel OEMs eventually update to a new initial yearly release, usually quite late, then rely on the backports to it for a year or more. Full Android security patches mean shipping the latest stable releases, which have been through significant public testing beforehand for quarterly/yearly releases and are not actually bleeding edge. Quarterly releases are as large as yearly ones but awareness of them existing is low. Android 16 QPR1 currently in Beta has more user-facing changes than Android 16.
We're working with a major Android OEM towards some of their future devices meeting our requirements and providing official GrapheneOS support. It will be their regular devices but meeting our requirements currently only Pixels do. Hopefully available in 2026 or 2027. There's no reason other devices can't provide comparable or better security than Pixels, but it's not easy or cheap.
Why do you think that's interesting? Google is highly respected for its security practices. Do you think Apple engineers use some special hardened iOS?
I am a long time GrapheneOS user, amazing project. One thing that is not clear to me is the support for NFC payments. Las time I checked, NFC payments on Graohene didn't work at all, but I am reading on this thread that some users do manage to pay via NFC? Did Iget this right? Mind explaining how?
I do not use banking apps (I only use banks that allow me to log in via browser using a 2FA which is not a proprietary app, like a FIDO key or other physical dongle), but do I get it right that Revolut would allow me to pay via NFC in this case? Is this something geo-dependent?
The issue isn't with NFC. It's passing the Play Integrity check that app developers optionally can use to prevent devices that don't pass the check from running their app, or remove parts of its functionality. IIRC I don't think any custom ROM's can pass the check. So you might be able to pay via NFC with a banking app if they don't implement the Play Integrity API. For Graphene's thoughts on the matter (2024):
https://grapheneos.org/articles/attestation-compatibility-gu...
Yes, I know the issue, but my question was more: is Revolut one of such banking apps?
6 replies →
NFC payments work on GrapheneOS. Curve Pay works with GrapheneOS and is available in the UK And European Economic Area (EEA). PayPal launched tap-to-pay which works with GrapheneOS but has very limited regional availability. Many European banks provide working tap-to-pay with GrapheneOS.
The issue is apps banning using a device not licensing Google Mobile Services or a non-stock OS via the Play Integrity API. Google Pay does this and a lot of banks outsource tap-to-pay to Google Pay instead of providing their own like many European banks. GrapheneOS users in Europe have multiple options. Users in the US often use a smartwatch for this purpose which includes the option of Garmin Pay rather than only Apple Pay and Google Pay.
The choices depend on the region. It would be nice if the Play Integrity API was forced to permit GrapheneOS via hardware attestation verification by regulators. We're pushing for it in Europe.
AFAIU, there's two forms of NFC payment:
- Adding your card to Google Wallet. - Using a banking app which actually implements payments via NFC.
Many banks used to implement the latter, but dropped it in favour of "just use Google Wallet". In the Netherlands, it seems to be all of them. This varies a lot per region.
I believe that the "just use Google Wallet" banks are the ones that don't work.
Also (as others have mentioned): many banks perform integrity checks, to ensure that you're using a software chain signed by Google.
> ""will never again be closely tied to any particular sponsor or company"". Work on GrapheneOS is supported by a Canada-based foundation created in 2023; there appears to be almost no public information available regarding this organization, though.
The company you're discussing is... GrapheneOS itself.
> GrapheneOS Foundation was created as a non-profit organization in Canada in March 2023 to handle the intake and distribution of donations. [1]
> GrapheneOS Foundation has been incorporated as a federal non-profit organization in Canada. It will be used to receive donations to pay developers and pay for infrastructure. It will also help to shield developers from attacks through the legal systems across various countries. [2]
[1]: https://grapheneos.org/history/
[2]: https://x.com/GrapheneOS/status/1638648643363258369
A question for strcat / other Graphene developers:
Can you clarify what can one expect from legacy extended support. Will old devices get any more updates? how long, how often, is it just security patches etc..
Thanks for you hard work!
Not a dev, but legacy extended support means that there are no more feature updates, i.e., no new Android versions or QPRs, only AOSP security backports. Obviously there aren't any firmware patches either, as these devices are unsupported by the manufacturer, who is responsible for delivering any changes to the firmware.
https://grapheneos.org/faq#device-support:~:text=The%20follo....
If I need to buy a phone made by Google to get away from Google, I'm just not doing it. /e/ doesn't support my current smartphone, either, and postmarketOS is not functional. At this rate, I think we're better off going back to dumbphones.
Even if you aren't concerned about the possibility of "backdoored hardware" (and I am not, for one), I'm still sympathetic to the argument that giving money to Google is morally wrong because it provides financial support for their data-harvesting business model (though since you use GrapheneOS, they'll only be able to use it to harvest other users' data, of course, not yours). Buying a used Pixel doesn't support Google financially, so perhaps that's more ethical.
See the response at https://news.ycombinator.com/item?id=44686811.
Thank you. I have the same worry. I'm not a developer, how could one tell there isn't some built in backdoor in the hardware? There was another HN posting on Graphene and asked the same question there with no answer.
The same thing could be said about any hardware. Pixels receive by far the most privacy and security research of any devices. They're by far the most secure Android devices and the only ones providing competitive security with iPhones. They're the only devices with even a reasonable level of security combined with proper alternate OS support. Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. These are very reasonable requirements for industry standard security features, standard updates and the ability for GrapheneOS to use those standard security features. There are other devices with all the major features listed there but not the ability for GrapheneOS to use all of them. Updates are a major issue for all non-Pixel Android devices including the ones advertising lengthy support.
GrapheneOS is working with a major Android OEM towards their future devices providing the expected hardware-based security features and updates, unlike their current devices. The purpose of GrapheneOS is not specifically avoiding Google but if you want hardware from another large tech company to use with GrapheneOS, you'll have that option. The initial goal for these devices is providing a similar level of security and long term support to what we already have with Pixels. In the longer term, we want to have add hardware-based security features unavailable on Pixels or iPhones along with hardening below the OS layer.
For now, Pixels are the only viable option for us to use. We're actively working on changing that but we're not going to simply greatly lower our standards and support devices where we can't adequately protect users. There's no evidence of any backdoor and it's contradicted by how exploits are developed and used. There is plenty of evidence that other devices lack comparable security.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... shows an example where only the Pixel 6 and later / iPhone 12 and later have brute force protection which holds up against the most sophisticated company developing forensic data extraction tools. We have access to more recent documentation showing the same thing.
Why do governments buy exploit tools from NSO, Cellebrite, etc. and develop their own if they supposedly have backdoors in devices? Why would using a device from Samsung or Sony protect against it if they did?
I am (very slowly) migrating from iOS to GrapheneOS, for the same reasons as OP (privacy, Apple's increasingly user-hostile and developer-exploitative policies).
Apart from migrations concerns, which are not GrapheneOS' fault, the main shortcoming I see is the lack of proper backup/restore, e.g. when switching phones. There is Seedvault, but I've found it unreliable.
Maybe my tinfoil hat is on too tight, but I always thought it was interesting that Graphene OS places so much blind trust in a proprietary black box security chip from Google that they pinky-promised to open source but never did.
Because they are a software project. When you're only concerning yourself with software, you have to pick some hardware and move on.
Going down the rabbit hole of secure hardware leads you down a slippery slope of eventually needing to create your own chips. And that's basically impossible these days for anybody smaller than Google or Samsung. So you do some research, pick the best you can, and hope for the best.
Perfect is the enemy of good.
You're worried about Google hardware but your requirement for a phone is that it must have Google Pay? Bizarre.
OpenTitan has open silicon (RISC-V) and is capable of open firmware (based on Rust TockOS) and is coming to 2025 Chromebooks, https://news.ycombinator.com/item?id=44416304. Hopefully a derivative of OpenTitan will ship in future Pixel devices.
Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.
Are you referring to the titan M2? why do you describe Graphene OS putting "so much blind trust in" it? I don't think they put much trust in it besides using it for storing keys and for their "Auditor" app
> I don't think they put much trust in it besides using it for storing keys
Ummm. Was this sarcasm that went over my head? Because if not, I have a hard time thinking of anything that requires as much trust as your private key storage.
If you think the org that produced the hardware might have backdoored it, architecting your software to avoid the TPM or whatever is dumb. Targeting Google HW at all is an unavoidable act of complete trust so you might as well use the HW properly.
Also, why would Google bother backdooring their special HW when 99.999% of its users are anyway gonna be running a totally Google-controlled proprietary SW stack?
> Targeting Google HW at all is an unavoidable act of complete trust
Doesn't the existence of FHE downgrade that to just "complete practical trust" at least? Not that I know of it being employed, but that it could be, and that it may be worth shouting out exactly cause of how niche and impractical it is.
1 reply →
How is it a black box? You can get the firmware trivially.
Does anybody else here see as problematic that this OS supports mostly Pixel, a Google phone?
Over and again people on HN make the following argument: "Google is a company that makes most of its revenue from ads and surveillance. Therefore, you should always assume that Google is spying on you". But somehow when it comes to Pixel people give it a pass?
Prediction: If Pixel isn't already hardwired to phone home and report on your activities, it will slowly become so over time, as Google realizes its interest. You know, as it happened with Android, Chrome, and everything else that Google touches.
I think it's perfectly valid to consider this as problematic (the GrapheneOS team certainly seems to think this is not ideal, for example). However - somewhat counter-intuitively - it's also valid to consider Pixels as among the most secure and most appropriate Android phones for something like GrapheneOS.
They write about their reasoning and criteria for device support here, for example: https://grapheneos.org/faq#future-device.
Your prediction is about a hardware product, and your examples are both software products (one is a browser and another is a mobile OS, both of which are platforms for running other software, and thus extremely well-suited to the task of reporting user data back to Google).
I'm not an expert, but baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
> baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
This isn't really a practical way of doing it. Google Play and Google Play Services having privileged access is more than sufficient.
3 replies →
This is just conspiratorial fearmongering based on vibes. If pixels somehow phoned home on a hardware level, do you think we wouldn't be able to tell? Do you think we wouldn't see it in our network logs? GrapheneOS supports pixels because they are currently the only devices that fulfill their list of requirements, like an actually usable secure element, hardware memory tagging, etc. They have said and continue to reiterate that they would support other devices that fulfill their requirements and seem to be currently looking into working with OEMs to move away from pixels in the long term. Just saying "you claim to degoogle phones yet the phone you use is a GOOGLE pixel, suspicious" is baseless nonsense.
> If pixels somehow phoned home on a hardware level, do you think we wouldn't be able to tell?
Yes.
> Do you think we wouldn't see it in our network logs?
If it's done on the baseband processor, no.
I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
But yes - your phone has a separate SOC, with its own operating system you can't access, which communicates with cellular networks. We don't know what, exactly, it's used for or what, exactly, is being transmitted. We do know it's used for location tracking because this is utilized by law enforcement somewhat regularly. But cellular triangulation isn't too accurate, not like precise location services.
1 reply →
See the response at https://news.ycombinator.com/item?id=44686895.
+1. It is kinda sad that folks seem to have lost critical thinking or even just some plain perspective on things.
They hear their favorite influencer spout something, and they parrot it everywhere. Google bad, hurr durr.
2 replies →
[dead]
See https://news.ycombinator.com/item?id=44686811.
Please don't copy-paste comments (https://news.ycombinator.com/item?id=44686876.
2 replies →
I'd install Graphene OS in a heartbeat on my Pixel if they'd add support for Google call screening and feature like Hold for me. Thise features are why I bought my pixel and it's too much of an inconvenience to go without them now. Spam calls have went down significantly and has saved me a lot of time.
I believe spam detection in the Google Phone app does work on GrapheneOS.
For spam, install their sandboxed Google Play, and then install Google's Phone and Speech Recognition & Synthesis apps. For SMS/MMS/RCS spam, you'd use an app supporting blocking (e.g., Google Messages).
I imagine that Hold For Me works if you also install the Google app and whatever other dependencies.
Been using it for the past two years and supporting the project. I personally love it but you do have to tinker a bit once in a while so I would hesitate to put it in the hands of my parents (though I bought them pixel just in case). Google Pay not working is mildly annoying (hoping to get PayPal or Curve eventually). Android Auto works but I didnt yet try to make voice commands work. Some app behave weird if you block access to the sensors (though it is nice to be able to do it). Sandboxed google play works great for the most part.
My workaround for using both NFC payments and Graphene OS is wearing a Google Pixel Watch (1). All other Google Wallet features besides NFC payments should work.
[1] https://discuss.grapheneos.org/d/475-wallet-google-pay/4
Sadly that solution does not work everywhere. In a lot of countries, Google Pay cards are added by the bank's app and it's on the bank to support rolling out cards on WearOS as well. A lot of banks in my country only support putting a card in Wallet on phones, but not WearOS watches (not sure if it is laziness on their part or whether security of WearOS watches is not deemed acceptable in general due to the lack of secure elements, shorter/no PINs, etc.).
Curve NFC payments work for me.
I love GrapheneOS. The only "issue" I had is that you are actually responsible for your own device, including taking backups.
Unfortunately my home server, which I was using for backups, was flooded and before I replaced it my phone died and I lost a lot of data...
you can always store encrypted backups to cloud storage
True, but unfortunately Proton Drive, which I use for "cloud" storage, does not supported the storage API that GrapheneOS' SeedVault supports for backups
I've been interested in Graphene OS, but being limited to just the Pixel phones is kind of lame. Have a Galaxy A55 I'd have liked to try it with.
Perhaps a newbie question, but since there's a lot of Graphene users here I thought it'd be best to get a human answer.
I have an old Pixel 5 which I stopped using because Google dropped Google Pay (tap to pay) on it. I moved to a new device (Pixel 9) for daily usage but still have the 5 laying around (due to low resale value).
At the time I moved, Pixel 5 was about 1.5 years (November 2023) beyond Android security updates. I still love the form factor (more than the bigger 9 I use now) and it has much more life left in it. I'd quite like to use this as a backup device for basic utility (camera, phone, SMS, basic read-only web use) and to take with me for runs and travelling.
Would installing GrapheneOS on this device likely make it more secure? Do Graphene releases work the same on all devices, or is it sort of device-by-device basis?
Pixel 5 should only be used to preview what GrapheneOS provided prior to October 2024 when Android 15 was released and we migrated to it. It's an end-of-life device and therefore lacks driver and firmware updates. We were able to provide some of those updates past the end-of-life, but not most, and we recommend against using it. We show a notification about it being an insecure device at boot. We continued providing all of our updates and the Android updates for it until the release of Android 15, at which point we shifted to supporting it via a legacy extended support branch based on Android 14 QPR3 with backported AOSP patches and minor fixes of our own. Our support for the Pixel 5 has been winding down further since it's increasingly insecure and we don't want people to use it based on us still providing updates. A Pixel 5 works as a way to try out outdated GrapheneOS but that's about it.
Using GrapheneOS on it would be more secure than the stock OS but it's going to be quite insecure regardless of the OS so we'd recommend just not using it. The intention of our extended support prior to Android 15 and then legacy ex trended support following Android 15 was harm reduction for people unable to afford a new device yet. That's essentially over now. We just didn't remove it from the site yet to avoid complaints. It informs people that it's an insecure device at boot so it's better than people getting misled into believing the alternate OS they've put on it keeps them safe when it doesn't.
Yes it will make it more secure (and faster!), but it is already receiving only bare EOL updates, but will definitely give it some life extension. See: https://grapheneos.org/faq#supported-devices
You won't get the full set of security measures (those require newer Google Tensor chipsets with ARM Memory Tagging Extensions, so Pixel 8 and later), but it's still going to be far more secure than any Android or even iPhone.
Regarding NFC payments, the apps themselves refuse to run on non-vanilla OSes due to spurious security concerns and Google's maneuvers behind the scenes, but there are reports that Curve Pay works, at least in the UK.
2 replies →
That's interesting. Thanks for the information.
I'll give it an install tonight. I'm curious to play around with it anyway and if I make minimal use of it, it should be pretty secure by it's use case.
1 reply →
My personal favorite feature of GrapheneOS is that we can toggle the network access permission. In the past, I'd have to root my phone just to be able to install a firewall to do the same. Big props to GrapheneOS!
True privacy is such a rare commodity these days. It’s a breath of fresh forest air to enter an OS unwatched, allowing your mind to be free.
Not to get too deep, but contemporary philosophy posits that our phones have become extensions of our brains (not only theoretically, but literally! See e.g. Andy Clark and David Chalmers, “The Extended Mind,” 1998). Our devices have access to profound parts of our lives— our habits, friends, desires, notes, thoughts… With something this fundamental, it’s vital to have privacy.
Thank you, Graphene team, for all the hard work you do.
Related:
Cops say criminals use a Google Pixel with GrapheneOS – I say that's freedom
https://news.ycombinator.com/item?id=44672521
The one thing that prevents me from switching my Pixel over is the lack of support for emergency services to see your location if you call the emergency number. I know this because I called twice while having GrapheneOS installed.
I do some watersports and always take my phone with me, so letting emergency services see my location is good for my safety in case I ever got into trouble on the water. I also have a PLB, but I like to have two devices for redundancy, as is best practice.
It sounds like you're in a region not supporting E911 but rather depending on Google's proprietary Emergency Location Service. We plan to make our own implementation of what that provides:
https://github.com/GrapheneOS/os-issue-tracker/issues/1174
GrapheneOS supports E911 and has our own network location implementation you can enable which gets used by it. Unlike Google's implementation, our network location is based on location position estimation similarly to iOS. Unlike iOS, we'll be providing full offline support for it.
Thank you very much for your work here!
This should be higher up.
GrapheneOS supports E911. It doesn't have Google's proprietary Emergency Location Services implemented as part of Google Play services which some countries depend on. We plan to implement the same standard it does for regions without support for a variant of E911:
https://github.com/GrapheneOS/os-issue-tracker/issues/1174
1 reply →
Counter-point: Pixel 9 with GrapheneOS, location services off, Netguard installed and active; I engage with emergency services on a regular basis for work and always receive the public record which tracks the incident. The reported coordinates are almost always within 100' of my actual location, so YMMV.
I have been using GrapheneOS en my pixel for almost a year and quite satisfied.
The docs for compilation are neat so I'm running my own build with my own signatures and my own repository of their AppStore for my third party apps that I also build from source.
I run only those apps on the main profile and then keep a private space (set to autokill on lock) for proprietary apps that require Play Services.
The article mentions the lack of a swipe keyboard, which is an issue for me.
There is an option though: Heliboard with a custom swipe configuration applied (which is apparently sourced from Google, I'm not sure how "grey" that is).
It definitely works as a swipe keyboard, but it's just not as good as GBoard. I will persist, however. I hope that it's learning at least...
Check out FUTO keyboard (it's only ok). Or install GBoard, download the language of interest, and then disable network access to it
I'm using Ginger, which works well. Once I used it once, it downloaded the dictionaries, and I could revoke network access.
I was tempted to use this but when I looked into the team behind it there seemed to be some issues as exposed by Louis Rossman here: https://youtu.be/Dl1x1Dy-ej4.
Instead, I installed CalyxOS and have been using it over a year now and I'm very happy with it. Check it out.
Hi there. GrapheneOS community manager here. It's a weird video to bring up without any context. Louis Rossmann made that video and leaked private conversations that were had fairly soon after the person in question was repeatedly swatted by someone who has a fan of the person Rossmann was voicing support for.
Unfortunately, Rossmann turned out to be very dishonest, which in retrospect makes sense, seeing as he has no issues with using Kiwi Farms. He's verified account there is named "larossmann". I suggest you look into it.
It's not just something he's done with GrapheneOS and the founder of the project. There are many videos, such as the one he did on Linus from Linus Tech Tips where he similarly misrepresented things and ascribed mental health labels on them.
Regarding CalyxOS, I would recommend people check out https://eylenburg.github.io/android_comparison.htm as a third-party comparison for various projects, including GrapheneOS and CalyxOS. They're not similar projects.
that comparison you are pasting in multiple replies has lineageos without micro-g.
2 replies →
[dead]
[flagged]
19 replies →
"Never meet your heroes". Also, the opening monologue to Tool's Third Eye[0].
The older I get the more examples I've come across of a person destroying their reputation by either self-over-exposure (social media) or just basic exposure via news of some outrageous or illegal behavior.
I don't have a problem with whatever line you choose to not cross, and I was once much more self-righteous, but I've more recently pretty much made the conscious decision to separate product from producer, art from artist, etc.
Theo Lengyel was recently arrested for murdering his girlfriend, and yet I will still listen to and enjoy Mr. Bungle's music.
Gary Glitter... I still like the song Rock n Roll Part Two.
J.K. Rowling has some controversial views on transsexual women, but that doesn't mean that the Harry Potter series is any less worthwhile reading than it was before.
ReiserFS
I still buy Nestle Quik occasionally
Steve Jobs, Bill Gates, Mark Zuckerberg, name almost any tech bro... (but not Steve Wozniak, he's a treasure)
Sports stars.
Musicians.
I wonder how many other things are worthy of protest if we knew all the facts about all the people who were involved in it's creation.
(I'm attempting to respond to the general concept of "he/she/they bad = it bad", not commenting on GrapheneOS vs CalyxOS or anyone's personal choice over where / what they choose to apply "he/she/they bad = it bad" to, other than saying that it should be a conscious decision not a reflexive reaction)
[0]: https://genius.com/Tool-third-eye-lyrics
This a video where he openly bullies someone, live streams their private messages where they're getting upset with him bullying them and repeatedly, blatantly lies about them including falsely claiming they're insane, etc.
Rossman lied about stopping using GrapheneOS and has continued using it after that point.
The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
He has done similar things to others, labeling them as insane and delusional.
> This a video where he openly bullies someone, live streams their private messages where they're getting upset with him bullying them and repeatedly, blatantly lies about them including falsely claiming they're insane, etc.
That is the most disingeneous take on the video. The claim this kind of commenters that freely carry water for the toxic GOS (ex-?) lead developer is the exact reason why Rossmann made the video. The evidence is all there for the public to see. Daniel does not get to essentially harass people he disagrees with after they have been asked to not contact them, threaten them to "publicly expose them" and get away scott free.
Being a genius at cyber security or autistic does not give one a free pass to treat other like garbage.
> The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
The video was made to expose the harassment of the project founder toward Rossmann, when the former contacted him out of the blue with frivolous accusations after they parted way a year earlier due to un-reconciliable disagreements.
> He has done similar things to others, labeling them as insane and delusional.
No evidence provided, as usual.
2 replies →
You are exactly right. To summarise for those who do not want to watch a video, the video shows communications with Graphenes lead developer in which he was extremely hostile and threatened Rossman. It also goes into how said developers hallucinates being attacked by specific other sites, like a Linux YouTube channel that obviously did nothing to him. His goons then attack those projects.
You have to be aware that you give that person root when you use Graphene. All possible technical improvements aside this is a very big risk. He claimed he would step back after the video released, then called that a lie and continued with everything.
Calyx seems to be the best alternative right now without such a risk factor.
I second this opinion, with some additional nuance.
While I don't think the developers necessarily hallucinates being attacked (i.e. given the nature of the project, I would expect them to be persons of interest, be it from surveillance agencies, or even state actors), the main issue with Rossmann is their claim that he is either personally directing harassment against GOS, or colluding with and encouraging other communities to harass (mainly Kiwifarms, Techlore, CalyxOS, and other Android related FOSS projects). This claim seems to originate then cascade from Rossmann leaving the comment "Informative, but unfortunate" on TechLore's video criticizing GOS's leadership. This is taken as explicit support of TechLore community's / KiwiFarms alleged harrassement on the lead GOS developer, and this has somehow been cascaded and blown out of proportions, and considered by GOS developers as evidence of Rossmann's wrong doing against them.
As mentioned somewhere else, I am using GrapheneOS since 2 or 3 years now, based on Rossmann recommendations. The software is very good, pretty much native Android experience, but without the extra alleged Google snooping / root access. Rossmann himself seemed to have stopped using it as his main device because of fear of retaliation given that the GOS devs could potentially target him. Better safe than sorry. I still use it because I am not that high profile of a person, and generally will use throwaway when it comes to discussing anything GOS related at this point. The overall leadership however, based on Rossmann's and later my personal interactions with them however, did leave a bad after taste.
10 replies →
Calyx has lackluster security practices, and even removes signature checking so they can sell microG as Google Play Store to apps. This is an objective statement, graphene OS is leagues ahead of anything on the market in terms of security, while calyx is basically just a custom ROM to tinker with.
As for the personal aspect, the lead developer is definitely not the best representative of the project from a communication perspective as he might not have that kind of social skills (based on his posts). [1]
But he (Micay) is an excellent security researcher, and has an excellent track record when it comes to prioritizing his users. There was a sponsorship in the beginning, where the legal entity, CopperheadOS tried to hijack the whole project. But Micay rather kill the project, than let the users' security suffer and revoked the signing keys. And I'm sure such a betrayal would cause anyone to lose a lot of faith in others' actions.
> Give that person root
Complete bullshit, what root?! And if anything, you are the one who are trying to discredit a project here, by sharing some dumb clickbait video.
[1] I see that there is now a project manager doing most of the communication, which is an excellent solution!
2 replies →
Can you elaborate on why this is a risk factor? What do you mean by saying we're giving him root? If a person is paranoid of being chased i would expect them to put even more effort into the security of the OS he develops, not to add backdoors. But please expand your own reasoning.
20 replies →
There's way much more to it than what you said here.
> extremely hostile and threatened Rossman
At the time, he was very upset. You know, because he was swatted multiple times. Of course he was upset when Rossmann showed his true colors and was trying to talk to him. Rossmann saw this as an opportunity and recorded it as it was happening. He tries to portray Daniel as crazy and people who attack the project and his friends on Kiwi Farms lap that stuff up.
It's not true that he stopped using GrapheneOS, though. He continued using GrapheneOS for months after that video, which you can see by watching his later videos.
> hallucinates
Repeating baseless claims that he's crazy.
> You have to be aware that you give that person root when you use Graphene.
What? This is a very strange way to say it. Either way, it's literally impossible for someone on the GrapheneOS team to target someone like what was claimed in the video. GrapheneOS devices don't send identifiers when they contact the update server. The update servers also only host static files.
> Calyx seems to be the best alternative right now without such a risk factor.
The "risk factor" is completely false. It's all made up to attack GrapheneOS, making the founder look like a crazy person, then people are scared of using the OS. CalyxOS is not a hardened OS and rolls back security in some ways. It's not the next best alternative for people who care about these things.
7 replies →
Why firefox in andriod is "more vulnerable to exploitation" ?
https://grapheneos.org/usage#web-browsing
Does Vanadium include the necessary APIs for uBlock Origin? Otherwise this seems like having a long explanation of how secure the windows are with titanium frames and bulletproof glass while the front door is wide open.
4 replies →
I've been using graphene since 2 weeks. It's been great. I'm only missing 1 feature: auto call recording.
Not automatic, but the GrapheneOS dialer supports call recording out of the box.
During a call, drag your buttons and they will scroll. The call recorder is the 7th button.
We recently made it so that the call recording option is not hidden away. If there are 7 options, it's RTT that will be the last one now, and we've made the scroll bar always be visible to make it clearer to people that they can scroll there.
Note that the author of the article has now added "corrections" :
Corrections/elaborations on some points : https://lwn.net/Articles/1031454/
Source: https://grapheneos.social/@GrapheneOS/114914602970489632
> Our community manager has provided a response to the recent LWN article on GrapheneOS with important corrections and context. The article had significant inaccuracies about the history of GrapheneOS, our organization and the details of what we provide. [.................]
As a long time GOS user I just want to remind what a joy it is to see my very old phone outlive flagships due to the lack of bloatware. I upgrade phones just for a single reason: it has been physically hit so hard over the years that it stops being physically functional.
I want Graphene OS on a non-Google compact smartphone.
Not "pixel compact", but the size of an iPhone mini.
Big thank you to the GrapheneOS team! I have been running it for a week now on my 9pro and the user / app sandboxing is great. If there's a way to donate with cryptocurrency or help contribute, let me know!
Check https://grapheneos.org/donate
My main complain by far to LineageOS is the necessity to wipe everything for major releases on my S10. That's not possible every year.
What about Graphene ? Can I get 5 years of updates without needing to wipe the phone ?
> My main complain by far to LineageOS is the necessity to wipe everything for major releases on my S10. That's not possible every year.
Are you sure that you are not just misinterpreting the upgrade instructions?
For the S10 a mandatory wipe-on-upgrade has last been the case when upgrading from versions _older than LineageOS 21.0_.
During the time where LineageOS 20 was the current version there was no requirement to wipe listed at all, so presumably it didn't exist then.
> For the S10 a mandatory wipe-on-upgrade has last been the case when upgrading from versions _older than LineageOS 21.0_.
Ah, that might be it. My current version is 21.
> If your device is running LineageOS version older than 21.0, wipe your data partition (this is usually named “Wipe”, “Format”, or “Factory reset”) .
https://wiki.lineageos.org/devices/beyond0lte/upgrade/
Yes ! Thank you, I can upgrade to 22 without wiping.
1 reply →
Yes, GrapheneOS has always offered OTA updates via the System Updater app. https://grapheneos.org/usage#updates It's set up to download and install updates automatically by default. Alternatively, you can install a signed update package via adb sideload. https://grapheneos.org/usage#updates-sideloading
Both the update client and the backend are open source, just like the rest of the system: https://github.com/GrapheneOS/platform_packages_apps_Updater https://github.com/GrapheneOS/releases.grapheneos.org
You don't need to wipe the phone when updating GrapheneOS. It's as painless as on stock Pixel OS. OTAs downloaded and installed on the background, just reboot the phone after.
Really feel a similar sentiment to a lot of others in the comments! I'm enjoying the recommendations other shared here. I _think_ this follows the rules of conduct for HN but let me know, I recently brained dumped about the following on my blog about the general experience setting up GrapheneOS: https://blog.matthewbrunelle.com/i-picked-a-really-weird-tim...
GrapheneOS "had" to reply to this article because they weren't happy with it's portrayal of events and LWN refused to edit a live article.
Par for the course with GrapheneOS. They always seem to take a good thing said about them and not be satisfied.
https://x.com/GrapheneOS/status/1948811620047536316
The submission is a bit old but let me try anyway since I see some user claiming to be Graphene community manager here. Let me first reiterate that GOS is an amazing project and that I am super grateful for your work. That said, I think the #1 missing feature is the lack of a robust backup solution. Las time I checked, there was an ongoing discussion about shipping an ad-hoc backup system for GOS. ANy uodate on this? Thanks!
I've been rocking it on mobile for a while, and went for a tablet (LineageOS there previously) this month.
The only real option for privacy and security which isn't swiss cheese.
I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
Has anyone else done the same?
Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
> I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
> Has anyone else done the same?
I did end up going for a Pixel + GOS. Although it is conterintuitive to use a Google device to get away from Google, according to GOS developers themselves, the Pixel series were the only devices that met their strict requirements for security.
From personal experience, been using it for almost 3 years now, and it gives you 95% of the benefits of Android while giving you back control over your phone, and being generally more secure.
Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
See https://news.ycombinator.com/item?id=44687530.
> Although it is conterintuitive to use a Google device to get away from Google
The purpose of GrapheneOS is privacy and security, not specifically avoiding Google, which is not what privacy is about overall. Many companies including Android OEMs have worse privacy practices.
> Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
There are a lot of ongoing attacks on the GrapheneOS project and our team including through fabricated stories and spin. People should look into the actual verifiable facts and look at who is being targeted with harassment and bullying. We defend ourselves from this including debunking inaccurate claims about the project and our team.
Thank you for the warning.
Is the camera with GrapheneOS as good as the stock android one? I get to use my wife's iPhone camera sometimes and it frequently shocks me how good and responsive it is. But I'm coming from a OnePlus 8 Pro, which never had a great camera in the first place.
3 replies →
I wonder how long it would take them/grapheneOS to support the new Pixel…
1 reply →
> I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
Fairphones lack proper security patches and OS updates from day one. /e/OS makes this substantially worse compared to Fairphone's own OS. Fairphone tends to lag 1-2 months behind on Android's standard partial security backports and a year or more behind on yearly OS updates. They skip the monthly and quarterly releases. Fairphone 5 uses the Linux 5.4 LTS branch which will be end-of-life in December 2025 with no plan to move away. Older Fairphones use end-of-life kernel branches.
Here's information from the author of the divested projects about /e/OS including data on updates from 2021 up until late 2024:
Issues with /e/OS: https://codeberg.org/divested-mobile/divestos-website/raw/co...
ASB update history: https://web.archive.org/web/20241231003546/https://divestos....
Chromium update history: https://web.archive.org/web/20250119212018/https://divestos....
Chromium update summary: https://infosec.exchange/@divested/112815308307602739
For the Chromium update summary from July 2024, note 128/135 was shipping each update on a given update path. /e/OS only shipped 12/135. They did not ship most Chromium security updates and skipped most releases. They're still skipping many releases and have significant delays for the ones they do ship.
Here's an article from another privacy/security researcher on /e/OS covering some of these issues:
https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...
As documented there, /e/OS has their own invasive services including user tracking in the update client. https://community.e.foundation/t/voice-to-text-feature-using... is another example where /e/OS sends user data to OpenAI without consent for speech-to-text compared to Apple doing it locally by default and Google at least supporting doing it locally and encouraging enabling it.
There's a third party comparison table at https://eylenburg.github.io/android_comparison.htm with a privacy and security focus. It doesn't currently cover invasive services added by operating systems or privacy/security regressions beyond patch delays though. It covers what is done with most of the standard AOSP services and how Google service compatibility is handled.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
The purpose of GrapheneOS is providing a high level of privacy and security. This requires secure hardware/firmware with important hardware-based security features and driver/firmware patches. Using a Fairphone with /e/OS is nearly the direct opposite of GrapheneOS.
> Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
An iPhone would be a far better choice for privacy and security than anything with /e/OS.
I'm secretly hoping my iPhone will spontaneously explode so I can justify buying a pixel for this
What if all this hype about GrapheneOS was actually deliberately invented by the CIA so that everyone who has something to hide would install a beacon with a backdoor on themselves? adjusts tinfoil hat
some things about the UX in this is so bad, which i love because it discourages me from using the phone more. every time i end a phone call i struggle hanging it up. i don't know how to go forward in the browser because the swipe always makes me go back, even when i swipe forward. it's using the ugly material ui components from google. it's great!
all of the privacy and security parts of the UX are good, though.
> some things about the UX in this is so bad, which i love because it discourages me from using the phone more. every time i end a phone call i struggle hanging it up. i don't know how to go forward in the browser because the swipe always makes me go back, even when i swipe forward. it's using the ugly material ui components from google. it's great!
Android has a standard system back navigation gesture based on the previous system back button. Apps integrate support for it. Chromium disables their back/forward gestures when using the modern gesture navigation in the OS. It would have made sense to have a forward gesture but Android never had that as something apps had to implement so it would only work in a small subset of apps and would be generally unavailable, which would be confusing.
Phone app has a button for ending the call. It's our fork of AOSP Dialer with minor changes including UI improvements. Calculator, Clock, Contacts, Gallery, Keyboard, Messaging and Phone are AOSP apps which we need to overhaul or replace. These look and function the same way Google's apps used to but are outdated. They're the open source projects which were abandoned beyond security patches after they forked them off into their own proprietary Google apps. Gallery and Keyboard will likely be replaced while the rest will be overhauled. We know these apps have a bad UI but our focus has been on the core OS instead of apps people can replace. We're beginning to do more work overhauling these.
very interesting. thank you for all of that information and the work you do. maybe one day i can contribute to the UX without being an HN cynic!
That project background reads suspicious as all hell, but then the thing does do what it says on the tin from all the news I see, so go figure.
Hi, GrapheneOS community manager here.
There are some corrections that we have contacted the author about regarding the history of the project. They initially e-mailed us to ask a few questions but seems to have maybe misunderstood something.
For clarity, GrapheneOS is the continuation of CopperheadOS, not a new project that spun off from it.
As an example, it can be seen that our repositories and legacy bugtrackers are ours:
-https://github.com/GrapheneOS/platform_manifest/forks?includ...
-https://github.com/GrapheneOS/platform_bionic/forks?include=...
-https://github.com/GrapheneOS-Archive/legacy_bugtracker/issu...
It's a direct continuation, but was renamed to GrapheneOS post the failed takeover attempt. GrapheneOS has persevered and is all the stronger for it. Over a decade now. :)
That is not correct, or at best a very questionable interpretation. Graphene is a continuation of the open source side of copperhead, but the copperhead project continued to exist even though the Graphene dev sabotaged it by deleting the cryptographic keys. Copperhead is the continuation of copperhead is my reading, Graphene is just also a continuation in a different project.
Why lie about something so easy to disprove by a bit of research? There were a bunch of articles about this back then, even wikipedia states it clearly.
1 reply →
Ah sorry, might have been unclear: by background, I meant the current governance and contributions situation they describe in the post.
It is insane the amount of "news" about GOS that somehow get things wrong. It cannot be coincidence but misinformation on purpose. On Twitter, GOS team have to often reply with the actual correct information, it is insane man.
Reading some comments here regarding hidden profile, security through obscurity doesn't and will never work. Add to that the fact that GOS is well known now, those people think that if they were forced to give their phone away, they won't have to disclose the hidden profile??? Newbies!!
I don't wonder why GOS team never bothered to prioritise this.
I have been using GOS for a few years now, it is perfect, full control over everything, the teams support is like no other and full transparency about everything, the release notes are like no other.
I really hope this project will never die.
I know you talking about my hidden profile. But let say you have a banking account you don’t want people to find out.
Currently you can only keep it on the main profile or any other secondary, which are easily visible.
With my approach you can minimise 99% of the risks for most users.
And even so, you can have 2 hidden profiles. So you can always show the decoy hidden profile.
Does GrapheneOS firewall provide port forwarding or is Netguard required
This is almost enough to make an Apple fanboy switch to android. Maybe I’ll get a second phone just to try it out. Which model would be best?
If it's just for trying out, then go for the cheapest second hand Pixel that's still supported by GrapheneOS and still has a battery that can hold charge for as long as you need it to for testing.
I bought a second hand Pixel 7a for my recent migration. Battery isn't great, but it's good enough to get me through a day.
Battery life improved a lot with the 9th gen Pixels other than the Pixel 9a due to the dramatically more efficient cellular radio. Set it to "4G" or the GrapheneOS added "4G only" as the cellular network mode and you should save a lot of battery life compared to having 5G enabled all the time. Battery life heavily depends on the apps, network and overall configuration. It's easy to end up with bad battery life with lots of apps doing their own push, etc.
GrapheneOS users tend to avoid using Google services when possible and this has a battery life cost when using apps like Signal with their own push systems. In the case of Signal, Molly is a fork with UnifiedPush support that's more efficient but it requires running a server to convert FCM to UnifiedPush since Signal doesn't support it.
Anything 8th gen and later would be best, as those models support MTE which is a huge security feature not present on 6th or 7th gen hardware.
Our recommended devices can be found here:
https://grapheneos.org/faq#recommended-devices
GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code. It requires hundreds of binary blobs from the vendor partition of a stock Android ROM, many of which have root access and have not been audited by anyone, including Google, who often lacks source code for them.
Beyond that, the GraheneOS team still controls a single signing keychain for all phones in the wild, which we have to assume is still controlled by Daniel Micay (strcat) as it has not rotated as far as I can tell since he mostly stepped away from public view.
He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness. Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I can't recommend GrapheneOS for any high risk use cases until:
1. they are able to find a device they can run 100% open source code on with no binary blobs
2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly
4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
So you're saying don't use a smartphone at all, which isn't possible, or use CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
This does not make sense at all.
> don't use a smartphone at all, which isn't possible
I run a b2b tech company in Silicon Valley and have not carried a smartphone in 5 years or had an LTE subscription in 6. I have a family and hang out with friends, mostly tech workers, at least once a week. I am online when I am at my desk or one of my family PCs, otherwise I am offline. It has been a massive productivity boost, attention span boost, and social improvement in every way.
I don't miss hours of doom scrolling a day and missing out on being present with friends and family. Took a few weeks to rewire my dopamine engine so the FOMO went away.
Phones -are- optional and if you think otherwise you might be an addict.
> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
It is better in one way: a reasonably stable person holds the keys to the kingdom. Personally I do not like having -any- central person controlling my devices, so I just opt out of Android entirely until that situation changes.
I am a supply chain security researcher and founded a Linux distro where no single computer or maintainer is trusted, so trust decentralization, freedom, and control in software are very important to me.
5 replies →
> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
CalyxOS lacks the current driver/firmware patches and isn't a hardened OS with similar privacy and security patches. There are plenty of worse options but people are better off using an iPhone.
Hardware and firmware is closed source in general and the complexity of that dwarfs a few dozen closed source driver libraries used on top of open source kernel drivers. Pixels have those libraries built with debug symbols and they're not hard to review. It's not obfuscated code and you're given the function names, etc.
Those few dozen mostly quite small libraries being open source instead of closed source with debug symbols would be nice and is something we want. With an OEM partnership, we can have access to the sources and build them with hardening even without those being open source yet. We can likely include debug symbols just as Google did for the most part on Snapdragon Pixels. Convincing a company like Qualcomm to open source those would be ideal, but it's far from being at the top of a rational list of privacy and security improvements which could be made.
> This does not make sense at all.
You can see he's once again making a baseless claim that I'm schizophrenic, delusional, etc. in his post here as he has done many times before. There's also the baseless claim that I believe wild conspiracy theories. It's not me making unsubstantiated claims about backdoors and proposing approaches to prevent it which disregard the hardware and firmware to focus on the OS having reproducible builds, which would not stop malicious changes hidden at a source code level. I don't think Hacker News should permit baselessly claiming someone is schizophrenic. It's not reasonable discourse, and neither is linking what's clearly harassment content from a Kiwi Farms as happens here regularly. I've never claimed GrapheneOS prevents hypothetical backdoors and certainly wouldn't claim reproducible builds (which we have) can somehow we used to prevent it for the OS.
We can make more use of the reproducible builds but enforcing anything based on it requires early access and more resources to fix reproducibility issues early to avoid delaying security updates. It will not avoid trust in the OS developers and the projects it uses itself. It can only reduce trust in the build infrastructure and people involved. Open source does not prevent backdoors. The small amount of closed source library code for supporting a modern smartphone SoC, etc. is also quite insignificant compared to the overall hardware and firmware complexity. Reviewing those libraries is also quite doable. Open source is not a hard requirement to review something, particularly with debug builds for most of it and no obfuscation. When we find bugs in this code with MTE, we get nice tracebacks with the function names due to the debug symbols. It's hard for us to make our own fixes for it, but not impossible. We would prefer if they were open source, but it's FAR from the most pressing issue and is something SoC vendors could quickly solve if convinced to do so.
> my best advice today to potentially targeted individuals is don't carry a phone at alil
Lol. I hope you like working with geese, but be careful, they can't be trusted!
Also, you are pretty much factually wrong on a bunch of items on your list. GrapheneOS still has room for improvement of course, but they are very ahead of anything else on every aspect. And where you are not factually wrong, you are just unrealistic. There is no 100% open-source hardware, period. This is complete "what color you want your dragon to be" category.
> Lol. I hope you like working with geese, but be careful, they can't be trusted!
Geese? That is offensive. I raise chickens.
I also run a successful tech company, and have a full EE lab, several full server racks, and more tech in my home than anyone I have ever met.
Phones are completely optional in modern society. We have just convinced ourselves we need them because doom scrolling and constant notifications are addictive.
Print your boarding pass, ask for paper menus, pay with cash, and arrange times and places to meet people and then actually be there on time. The rare times you really need to do online work on the go, bring an actual computer with a real keyboard. Free wifi is everywhere.
Works just fine, and as a bonus your time away from home becomes mostly invisible to marketing firms.
> Also, you are pretty much factually wrong on a bunch of items on your list.
If you are going to call me misinformed, please take the time to prove it so I can stop sharing information I otherwise have no reason to believe is incorrect.
> There is no 100% open-source hardware, period.
Multiple fully or mostly open hardware computers exist. They just cannot run android.
MNT Reform, Precursor, and Talos II are the top three that come to mind.
Those are lightyears ahead in openess and auditability compared to anything Google produces.
1 reply →
> GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code.
It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.
Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.
> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.
There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.
> Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.
> 1. they are able to find a device they can run 100% open source code on with no binary blobs
There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.
A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.
> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.
> 3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly > 4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.
AOSP having a regression causing a timestamp to be added somewhere isn't a reasonable justification for blocking security updates. No system without the ability to investigate the cause and determine if it's okay would be reasonable. We would need to finally have early access to new Android releases to test this in advance and have fixes ready to go prior to the stable releases. We do not currently have this early access but will likely obtain it from the OEM we're working with soon. We would still need additional resources to have ongoing testing for this and fixes for any relevant regression that finds. Porting to new releases prior to them being stable and specifically testing this would be needed.
We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue.
In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works?
If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources?
> Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible.
> Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design?
> If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it.
He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.
I wish to use Graphene OS, but I can't force myself to buy a Pixel Phone, I don't like the design.
Graphene is a fantastic operating system for Pixel devices. Simple, reliable and with plenty of security and privacy features to make you feel warm and fuzzy. System updates are automatic, actual phone functionality is flawless, perhaps the only complaint to be had is the quality of camera, which probably lacks proprietary drivers. Signal works fairly well - even without abusive Google Services installed, making this a perfect daily mobile driver. Much gratitude to the developers of this project.
GrapheneOS does not degrade the camera quality at all. The quality will depend on the app being used. If you use Pixel Camera on GrapheneOS, you'd be getting the experience you'd get on stock OS using that same app. Similar for our built-in camera app.
Didn't try it in a long while, but I remember being able to run the proprietary pixel camera app just fine.
[dead]
While a big proponent of this, to my mind, it seems a bit counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks, creates a bad patch and empties my bank account.
Hi there. GrapheneOS community manager here.
It's important to note that GrapheneOS is not some niche barely-used project. It has existed since 2014 and is used by multiple hundreds of thousands of people at this point. There are also many eyes on the project through people forking it to make their own products, people maintaining their own builds etc. GrapheneOS is also reproducible in addition being open source.
On our side, we are very particular about accepting outside contributions if they don't need meet our standards, and code is heavily reviewed within our team before being merged.
I'd also recommend giving https://grapheneos.org/faq#audit a read through.
All in all, your concern, while valid, isn't something that's likely to happen precisely because we're very aware of situations where it has (see xz) and are therefore very vigilant. The kind of thing you're worried about isn't likely to come from a big project like GrapheneOS that has many eyes on it, but rather something small that's used everywhere and barely has a couple of devs working on it, if that (again, see xz).
However, do you consider yourselves as able to resist a nation-state level adversary with resources dedicated to compromising you?
I think of two things, the Solar Winds build corruption, and putty's mishandling of e521 keys.
What is your vulnerability to a similar disaster, exploited or not?
1 reply →
> it seems a bit counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks, creates a bad patch and empties my bank account
From what I have observed, nobody is held to account when there is a software issue, commercial or open source.
>counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks
Open source software is everywhere. Do you think Microsoft or Redhat going to be held to account if they accidentally added some backdoored OSS code? Moreover all of the development happens in the open and you can build it yourself. I'm not sure what the alternative is. Just trust Apple has their shit together with iOS?
Google also cannot be held to account, its legal team out resources countries and if you attempt to litigate at best they will just keep you busy until you're bankrupt.
At least graphene wouldn't be expected to shield the perpetrator.
You say the same thing about Linux? This feels like old open source FUD, the only case I know of off hand is the xz util backdoor and that was found and patched before the malicious patch had made it into the main distribution channels.
This take demonstrates most people's inability to rationally threat-model: you would rather trust a known-abusive authority than an unknown-good samaritan, because of a false notion your bank balance is actually significant enough to warrant such an attack.