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.
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.
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.
The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
Depends on your threat model. If Google, low-effort scam apps or being profiled by apps are your only adversary, then that's true. If random threats on Internet or APTs pwning your phone, or being forensic-proof are part of your threat model, then Calyx is strictly worse than stock.
The table shows CalyxOS has substantial delays for important privacy and security patches. It currently doesn't provide the 2025-06-05 patch level. It's better than LineageOS and /e/OS in that regard but still reduces privacy and security through significantly delayed patches. CalyxOS also weakens parts of the privacy and security model through the privileged functionality that's added, which simply isn't covered by the comparison table.
> The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
On Pixels, CalyxOS is missing current Android privacy/security patches. GrapheneOS doesn't support those other devices due to lack of a reasonable level of security. Each of those extra devices has significantly delayed privacy/security patches and lacks important hardware-based security features. Despite all the marketing about long term support, Fairphone 5 uses Linux 5.4 which is end-of-life in December 2025 with no plans on their part to move to a supported kernel branch afterwards. Earlier Fairphones are stuck on older end-of-life kernel branches. Those devices are missing basic updates and security protections. Those don't provide proper long term support, so if someone does have one it won't be long before it's time to buy another device.
But there is still no way to reset/spoof android device ids, and the apps can reliably identify the user after reinstalls.
you got it wrong way around
the CONSUMER criteria is "we want better independent security ON DEVICES WE ALREADY OWN"
complaints like in this thread are symptoms of unfullfilled demand - and they can't be solved by saying "oh gosh, what a stupid demand that doesn't agree with our supply"
vendor: not possible
you: unfulfilled demand
me: the way I see it, you get a product for free if you fulfill certain conditions. If not, you buy these conditions.
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.
The unfortunate thing is that they make security promises which aren't upheld in practice (such as shipping security updates on time), so it doesn't inspire confidence as an OEM you could trust to properly support a device for multiple years.
We're hoping that there will be people who will enjoy a device from the OEM we're in talks with - we know that there are many people who for various reasons don't want a device from Google, so this will at least offer an option for people who want to use GrapheneOS on a non-Google device.
At the risk of doing their work for them, that seems like a near ideal partnership opportunity for graphene, so it’s extra sad to see.
Google provided resources for the Linux kernel to extent LTS support for 6 years for their 5 year guarantee with the Pixel 6. It ended up not being needed since Pixels began moving to newer Linux LTS branches. The official Linux kernel LTS support is back down to 2 years. The 6 years was meant to benefit all Android devices but it proved to be too difficult to do well and it makes more sense to invest a far smaller amount of resources moving to new LTS branches.
Fairphone presents providing an Android OS release 3 years after it was released as providing 3 more years of extra support compared to an OEM releasing it in the month it was launched as their final update. That doesn't make sense.
They've repeatedly had blatant security flaws such as using publicly available private keys for signing the OS on the Fairphone 4. These issues are downplayed rather than being acknowledged.
There are important security features missing, but the main issues are the lack of proper updates and their approach to security flaws being reported and discussed.
Many Android OEMs are a better fit for a partnership with us and we're working with one.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a better thread about this than the one you linked.
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.
In any case, thank you for all the work so far!
> 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?
https://discuss.grapheneos.org/d/8439-mte-support-status-for...
> Hardware memory tagging is going to provide a massive increase to protection against remote exploitation for GrapheneOS users. It's the biggest security feature we'll be shipping since we started in 2014.
It provides the ability to tag 16 byte granules of memory with 4-bit tags where only pointers with the correct tag can access the memory. This provides an approximation of memory safety very useful for security.
As an example of how it gets used, our implementation of the system allocators via hardened_malloc tags each allocation with a randomly generated tag excluding the adjacent random tag values and previous random tag value for the slot. It has the standard setup of a single statically reserved tag (zero) used for free memory but adds 3 more dynamic exclusions. This provides deterministic detection of small overflows, linear overflows, many forms of use-after-free and fallback to probabilistic detection of other spatial (bounds) or temporal (use-after-free) memory safety issues. We use a lightly modified variant of the standard MTE integration for PartitionAlloc in our Vanadium browser, but we plan to improve it to match hardened_malloc. We use the standard Linux kernel implementation for the internal Linux kernel allocators which needs a lot of improvement.
> why target requirements that even most desktop computers don't meet?
Desktop computers are far less secure than an iPhone or a Pixel with the stock OS. GrapheneOS exists to provide a higher level of privacy and security than those. GrapheneOS is primarily aimed at mobile devices which are almost entirely 64-bit ARM. Hardware memory tagging (MTE) is a standard ARMv8.5 / ARMv9 feature provided by every standard ARMv9 Cortex core. MTE is only missing with custom CPU cores or cache while cutting this corner.
Pixels are not the only devices providing MTE. Exynos and MediaTek have provided it and Snapdragon should be providing MTE starting at the end of this year. The only reason Snapdragon is late to the party is due to their custom cores/cache.
We're currently working with a major Android OEM towards multiple of their future devices meeting all of our requirements and providing official GrapheneOS support. They view all of our officially listed requirements as completely reasonable and a target they can meet for their next generation of devices.
The purpose of GrapheneOS is providing a high level of privacy and security, not making security less bad for devices people already have. Hardware and firmware security matters quite a lot and software security depends heavily on hardware-based security features including MTE. Nearly all GrapheneOS users buy a device to use GrapheneOS and that would still be the case if we supported several other devices. The vast majority of Android devices lack proper security patches for drivers/firmware, are missing important hardware-based security features and don't provide serious support for using another OS where the security features can be kept intact. Samsung's flagships are closest to meeting our requirements after Pixels but do not allow another OS to use verified boot, important secure element features and more. Samsung permanently cripples their devices if they're unlocked and voids the warranty, unlike Pixels.
The reason we're working with an Android OEM is because existing non-Pixel devices don't provide a base we can use to provide what GrapheneOS offers. It would be missing huge parts of the core features elsewhere and would be worse in significant ways than the stock OS. It would go against what we're trying to achieve to have people buy devices we can't properly secure. Long term support for drivers and firmware is also important because people use devices more than 3 years from launch in practice. Pixels get 7 years of proper support from launch, which is unique. A couple OEMs market their devices as having similarly long support but the updates are significantly delayed and far less complete.
We've had numerous opportunities to work with OEMs where they weren't able to provide our requirements. We simply aren't interested in having a far less secure device with GrapheneOS as the stock OS. We expect our requirements to be met, and we think the OEM we're currently working with is fully capable of providing what we need. It will hopefully be available in 2026 or 2027. The initial goal is not doing better than Pixels, just providing a competitive alternative for people who want to use GrapheneOS on another brand of device.
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.
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.
You can have the best alarm system in the word, if you leave the back door open and anyone can just walk in from the street.
So just give me that alarm system for my tent, please. It will do fine for my case.
Our requirements are not at all exotic or outlandish, the fact that most OEMs don't meet them says more about how far behind most OEMs are, rather than our standards being unrealistic. We've also been told that they're not unrealistic in practice from numerous OEMs who want to build a device that meets our requirements.
It is also important to note for Pixels specifically that since the 8th gen Pixels, they receive 7 years of support. Additionally, they partner with iFixIt to provide official replacement parts for the duration of the device's life. I'd say that's pretty sustainable, especially when you consider that the Fairphone doesn't actually provide proper support for the amount of years they claim, since they have consistent delays in providing patches.
You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones
Yeah, that's completely how security works...
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.
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. :)
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.
> Fuzion24 / platform_manifest Created 10 years ago Updated 10 years ago
Instead, I installed CalyxOS and have been using it over a year now and I'm very happy with it. Check it out.
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.
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.
You should watch Rossmann's video on Linus - he has a habit of doing these hit pieces.
He never called Linus "insane" or "delusional" as the parent post claims, hence the request for evidence.
He (rightfully IMO) criticized some of his business practices (Honey, BilletLabs, "Trust me bro"), and quite a few more controversies which LTT was embroilled in.
He criticized Linus' behavior and lack of accountability based on his personal interaction with him, as well as publicly available evidence. At worst, called him a narcissit. If anything, he is vindicated by all the LTT apologies videos (one of which Linus and other staff even make puns and sponsor placements ...) that follow up each controversies.
Any more specific evidence you think show that "Rossmann has the habit of calling random people insane and delusional". I am willing to bet you have none.
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.
I am sure you have proof for such a justiciable acccussation? The perpetrator is in jail and you can link to the court proceedings for example? You are surely not just regurgitating another hallucination by the Graphene developer, right?
Disclaimer, I am a GrapheneOS user. I was introduced to GOS by Louis Rossmann initial 2 or 3 videos talking about giving them a FUTO grant, as well as praising GOS and showing how it easy it was to install, and how it gave back control to the user, and all the good things that GOS genuinely provides.
I have (unfortunately) followed this saga and went down the rabbit hole since the very beginning. To my understanding based on publicly available data, the key "evidence" put forward by GOS developer(s) / community manager would be:
1. Louis Rossmann leaving the now pinned comment "Informative but unfortunate" on TechLore's video on the leadership of GOS. They claim this is Rossmann showing support for Techlore and his community to (allegedly) harassed the (at the time) lead developer of GOS.
2. Louis Rossmann having KiwiFarm account. Yes, KW is a cesspit. However, all of Rossmann's message on the board mostly focus on either addressing misconceptions about himself, or promoting right to repair and similar topic. This can be easily checked, and at no point there is any public evidence of him supporting harassment toward the GOS developers.
3. Louis Rossmann being acquainted with leadership of other de-googling Android OSes (CalyxOS mainly I think) and also giving them a FUTO grant.
Essentially, "guilt by association". I know this because I have asked the community manager (goes by mbananasynergy on HN, and similar aliases on other platforms), and that is what they provided as "evidence" for Rossmann being guilty of harassing or promoting harassment against them (along with mentions of having 2 millions of USD worth of backing and ready to sue Rossmann, which has not materialized as far as know since ~1.5 years ago).
I want to preface by saying that GOS is really a good software, I have been using it for 2 or 3 years since then, and no complaints on that side. My biggest gripe however, is indeed with the leadership and management of the community.
I created a new account instead of posting this with my main because the leadership is in my experience very abrasive, to say the least. I have been banned without appeal from their Mastodon for leaving "thumbs up" smiley on : 1) messages suggesting the GOS devs to do an interview with Rossmann (as he did with other projects that received a FUTO grant) to further spread the word, or 2) messages suggesting to clear up the misunderstanding between the devs and Rossmann.
Any disagreement on their official narrative, or contrary opinion (even in good faith) leads to bans if they are in control of the platform, and accusations of collaborating with groups that harass the developers. Even here, anything contrary to that narrative will receive the usual wall of text describing the poster as sockpuppets, harassers directed by Rossmann, Techlore, CalyxOS, or any other projects GOS developers are beefing with.
I am disappointed by the situation, because I think GOS could have a larger presence and contribute to raising awareness about the importance of data security, but their leadership seems to be a considerable roadblock on that direction.
Unfortunatelly, EVERYONE, from all parties, fire shots for the wrong reasons, which perverts the discussion.
When you say to people to not use GOS because the lead dev is paranoid or the community is hostile you are throwing out the baby with the bathwater. The value GOS brings is undisputable. The quirkiness of the leadership is also undisputable. Let's decouple the two. If you wish for the community to get better, become yourself the better contact point amd generally focus on suggestion on that matter. Don't say to people to not use arguably the most secure android rom!
I used to respect Rossmann a lot, but he fell in my eyes both for the LTT and the GOS incident. I have been watching LTT since a kid and I know that his has grown to be a jerk without looking at his private communications, but his competitors fired shots at him for the wrong reasons (honey case) and so did Rossmann, riding the wave.
If you want to criticize someone for being a jerk do it, but do it for the right reasons, don't muddy the waters by injecting other stuff in the discussion.
It's one thing to separate the artist from the art, but I think that analogy does not apply when it comes to e.g. an operating system which essentially handles all of your private data. If anything, not being able to separate the art from the artist is the exact reason why GOS exists, the artist being "Google" and all their controversial practices. (Edit: or a simpler analogy, would you trust the food (art) of a cook (artist) that threatens to ruin your life ?)
The OOP is entitled to express his informed opinion and even provided what he based it upon. As a user, I think that is important context when it comes to picking something as sensitive as an OS.
> I used to respect Rossmann a lot, but he fell in my eyes both for the LTT and the GOS incident. I have been watching LTT since a kid and I know that his has grown to be a jerk without looking at his private communications, but his competitors fired shots at him for the wrong reasons (honey case) and so did Rossmann, riding the wave.
I happen to have a similar background as far as LTT (weekly WAN show and what not) and Rossmann are concerned As I mentioned before I (unfortunately) went into the GOS incident rabbit hole and overall still think Rossmann was principled. As far as Rossmann's criticism of Linus about the LTT Honey case, perhaps he could have had a more nuanced approach, yes. Regarding the BilletLabs cooling block, or the "Trust Me Bro", his criticism was substantive, and came from his own business background on dealing with customers (although you can argue that Rossmann has high standards). I don't think Rossmann "fired shots for the wrong reasons", namely since LTT has publicly acknowledge the issues.
> If you want to criticize someone for being a jerk do it, but do it for the right reasons, don't muddy the waters by injecting other stuff in the discussion.
Just curious, but who is muddying waters, and how ?
In the context of this whole rabbit hole, pretty much all of the parties.
When you bring someone's dirt put in the public, not to support an argument but just to attack them because you don't like them, uou are muddying the waters.
MegaLag did it for Linus
Steve did for Linus
Luis did for Linus
Linus did for Steve
Linus did for Luis
Henry did for Daniel
Luis did for Daniel
And of course Daniel pretty much does for anyone :p
These were not conversations based on logic, each had a reason to dislike the other and dag up dirt for clicks and for leverage.
To take the specific case of Rossmann, how is he muddying the water ? If anything, he is clarifying his position on stopping using GOS. It is important context, not "muddying the waters".
You yourself say that: > And of course Daniel pretty much does for anyone :p
And Rossmann brought up the receipt to corroborate the GOS developer hostile behavior toward him, which was his argument. And even if you take it further back to origin, the "Informative but unfortunate" comment, this was not targeting GOS's quality and claim of security. The argument in that specific case was the questionable behavior of the leadership, which you seem to agree was not a "conversation based on logic". If some people can't be reasoned with, what is Rossmann supposed to do ? He "agreed to disagreed" and cut contact with the dev, kept the GOS situation under the lid as it was still a project he liked, but that was apparently not enough to keep that developer at bay ...
Just stop interacting? When you have an argument with your colleague, do you go on twitter and post all your conversations and tell everyone how irrational he is? When you argue with a relative do you make an 1hour long video detailing how they missbehaved? Why did Luis felt the need to make content on his popular channel to expose someone with problematic behavior?
Clicks. Money.
And on top of that he is attacking his work which is actually very valuable.
I don't care if Luis is on the right side of the argument. If he was chatting me up on the bus and told me about it, i would be glad to know. Attacking a person on public for money and leverage is bs.
Edit: Especially in the case of Daniel, if you have made the conclusion that a person is trully paranoid, this is a clinical situation, do you expect to "fix" them by exposing them? Or are you throwing more gas to the fire?
Rossmann did exactly in September 2022. If you actually bothered going through the document, would could see that they had an initial interaction that did not pan out. Rossmann wished Daniel best of luck and said he would not be further involved because of the disagreement.
On his social media and other platforms, Daniel did not stop talking about how Rossmann was allegedly attacking (without any concrete evidence). Daniel himself contact Rossmann again out of the blue with borderline threats blackmail umprompted, as can be seen in Rossmann's video on "Why I deleted Graphene OS". Asking nicely did not work, and Daniel threatened to "publicly expose him", so he went public. What was he supposed to do ?
> Clicks. Money.
Rossmann channel is not making him money. It is not monetized. His business is about repairing Macbooks and data recovery. This drama does not generate him money. He does not get paid for people using CalyxOS etc... over Graphene OS. There is simply no incentive
> And on top of that he is attacking his work which is actually very valuable.
What "attack" ? Is a comment "Informative but unfortunate" on a video criticizing Daniel's behavior an attack ? Is giving the project a 40K USD grant no string attached an "attack" ? Is proposing an to do interviews to further promote the project an "attack" ? Is making videos to actually dispel misconceptions about GOS and praising how good it is on his channel and "attack" ? None of you who carry water for Daniel and his toxic behavior have any evidence of Rossmann directing attack at GOS, and even loss so Daniel himself.
> I don't care if Luis is on the right side of the argument. If he was chatting me up on the bus and told me about it, i would be glad to know. Attacking a person on public for money and leverage is bs.
Again, no evidence it is about money and leverage.
> Edit: Especially in the case of Daniel, if you have made the conclusion that a person is trully paranoid, this is a clinical situation, do you expect to "fix" them by exposing them? Or are you throwing more gas to the fire?
Keeping it private the first few time did not seem to work, might as well try. If Daniel himself is beyond help, at least make it so other people know what kind of person they are entrusting they phone security and privacy to.
By the way, I managed to find their archived conversation which are not available anymore in the video description. Curious about your opinion on it: <https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
> an operating system which essentially handles all of your private data.
This is exactly why one should continue using GrapheneOS as it is by far the best, most secure and private option. If you do not agree with one project member about something that is not related to the technical features of the project, it does not matter, since you can not be targeted with any GOS updates. Same updates would have to go to all GOS users and as stated before, the previous project leader has a stellar reputation when it comes to their work and prior actions regarding users security and privacy.
> the artist being "Google" and all their controversial practices
You believing this is a problem, you should then be using an iPhone anyway.
You are worrying GOS devs might push a malicious update, even when there are no proofs of that happening? What prevents the same from happening with other projects that are already inferior in every way? You are implying people should switch to less secure options because of this one thing that also applies to all other options? It does not make any sense and seems dishonest.
I will concede that my statement is not the most accurate. However it is not a matter of logic, but description. What I meant to say is that the OS is the substrate of all applications running on the phone, and all the relevant data. Having privileged access to the OS opens the user to the most critical vulnerability.
> This is exactly why one should continue using GrapheneOS as it is by far the best, most secure and private option. Rationally speaking yes. When the developer of the OS threatens to "public expose you" and accuses you of directing harassment / swatting against them without evidence however, a layman (that has no obligation to understand how GOS updates work) is justified in feeling unsafe or uncomfortable using said software. A determined enough (hostile) developer could find a way to target him personally. Even if you personally feel it is unlikely, the probability is ultimately non-nil.
The GOS x Rossmann matter was never a technical issue, it was about the (in my opinion) toxic approach of that lead GOS dev to Rossmann. A huge misunderstanding I dare say. But the damage was done and Rossmann is within his right to criticize his approach and stop using his software.
> Same updates would have to go to all GOS users and as stated before, This is a irrelevant point. Stuxnet was harmless to most systems, while still targeting very specific Iranian systems. All GOS user, (me included) don't audit the code every time there is an update.
> the previous project leader has a stellar reputation when it comes to their work and prior actions regarding users security and privacy. Stellar reputation is quite the exaggeration. That lead GOS dev has an indeniable controversial and abrasive reputation. Imagine the ingenuity and persitence that you perceive about his "work and prior actions regarding users security and privacy", and imagine it being deployed toward someone that dev does not deem as a "simple user", but a personal enemy / enemy of the project ? Nobody would want to be on the receiving side of whatever such person is capable, and neither does Rossmann, understandably.
> > the artist being "Google" and all their controversial practices > You believing this is a problem, you should then be using an iPhone anyway.
I will assume you are good faith, and just misread what I wrote. My point was that in the same way we cannot trust Google software (at least privacy wise) because of the profit incentive of its leaders, another OS like Graphene OS can also inspire distrust if their leadership demonstrate hostile behavior (even if just toward a single specific user).
> You are worrying GOS devs might push a malicious update. Me personally, no. I am not worried. I know enough about software to know that it is unlikely. And I am a nobody. Rossmann is, because he is a layman, and the lead dev was clearly hostile against him. We don't get to deny his perspective.
> even when there are no proofs of that happening ? Not having proof of it never happening so far, is not a proof that it will never happen in the future.
> What prevents the same from happening with other projects [...] Nothing prevents it, and no one involved either in this discussion, nor in the original incident stated this.
> You are implying people should switch to less secure options because of this one thing that also applies to all other options? Again, nobody implied that. I personally never said it. My argument was that I found the leadership lacking, and to a certain extent, the community (examplified by this kind of "water carrying" arguments you have presented). Even Rossmann himself never said it. He only made public his reasons for not mainly using GOS since the altercation, and still recommends it whenever he discuss phone privacy. The grandparent however did bring up this issue with GOS leadership as a data point, which would still be good to have for prospective GOS users.
> It does not make any sense and seems dishonest. If anything, you moving the goal post with such strawmen arguments is what seems dishonest...
> another hallucination by the Graphene developer
I'm going to assume that by you saying "another" you mean that there were hallucinations before this one.
What you are doing here is repeating baseless claims that they're crazy, which is complete nonsense. This is exactly the kind of problematic stuff that shows up on Kiwi Farms. Again, Rossmann has an account there and some of his videos seem to be made to appeal to Kiwi Farms users.
Which is not what I'm talking about. You claim you know who did it. Where is the proof?
Though I never doubted that the swatting attacks occurred, I am noticing now that you mention police reports without linking them. Let me guess, there is nothing online, no police press release, nothing?
> I'm going to assume that by you saying "another" you mean that there were hallucinations before this one.
Yes. Like the attacks he hallucinates from project like Calyx and from the Techlore Youtube channel, and the documented way he turned on Rossman. Always claiming there is proof he already provided for the evil machinations of the others, with references going to other claims of having provided proof before, with none to be found anywhere down that chain. That is pretty easy to categorize behaviour. I personally would not call him crazy (who the fuck is "they"?), that seems to be hurtful, but I am confident in seeing signs of a mental disorder there and stating that publicly.
> Again, Rossmann has an account there and some of his videos seem to be made to appeal to Kiwi Farms users.
Complete Bullshit. Provide links to the videos, otherwise that is another evidenceless attack and just confirms your pattern.
No. Nobody claimed to know the actual identity of the person.
> Like the attacks he hallucinates from project
They're not hallucinations.
> I am confident in seeing signs of a mental disorder there and stating that publicly.
Not a doctor, but is confident in their diagnosis of someone they don't actually know after watching some YouTube videos.
> Complete Bullshit.
I mean that these kinds of videos where he portrays people as crazy appeals to Kiwi Farmers. His verified account there, him participating there, and him making videos that do appeal to them all add up to me coming to the conclusion that they _SEEM_ to be made with the _intent_ to appeal to Kiwi Farms members.
Your founder sure did, in https://grapheneos.social/@DanielMicay/110267918805461751.
> They're not hallucinations
Sure buddy. And you will present proof any day now.
The person who swatted Daniel spent days raiding our Matrix chat rooms, posting gore and CSAM. We know it was them who did it, because they bragged about it during their raids before we had made any public comments about it happening.
We don't know who the person is, and neither does the police. The details we have about what was said during the calls was provided to Daniel via the police, especially since it happened 3 times, not just once. Thankfully after the first time the responders were somewhat aware of what was happening so it wasn't as scary.
Your deflection is genuinely concerning.
I assume you're not disputing that Rossmann has a verified Kiwi Farms account, that much is well documented.
The above video refers to a video by Destiny (https://youtu.be/ba383Zux0Mo) where he spends a bunch of time defending Kiwi Farms. Rossmann making a video about it and joking about "lolcows" is what has contributed to people at Kiwi Farms worshipping him, and his fan starting a thread about Daniel there where people tell him to kill himself.
Stop defending this stuff and finding every opportunity you can to try and gaslight others - it's weird.
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)
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.
You just don't know what will happen is what I'm saying.
The "he has root" is also a reference to ubuntus shuttleworth.
You mean who tried to hijack the project in a very questionable direction, harming their users, he rather lighted the project on fire then let the users' security be compromised?
If anything, that is the greatest compliment you could give him.
Also, this is fud that he can push any kind of code, like you can easily check any part of the pipeline.
On one hand, sure it can be a compliment. On the other hand, it only increases the perception that he is could enact significant harm if he ever comes after you.
> Also, this is fud that he can push any kind of code, like you can easily check any part of the pipeline.
Who is "you" ? Neither Rossmann, neither me (software dev albeit not in cybersecurity), and even less so the average GOS user, and I would venture to guess that neither you can audit GOS code with enough confidence to declare that the risk of an exploit or backdoor being introduced is zero. Open-source is not a guarantee that code or software is secure (for e.g. CVE in xz utils and many such cases).
Edit: some clarifications.
But that would be incorrect. It's not possible for anyone from the GrapheneOS project to target a GrapheneOS user that way. Look into how updates and the update servers work.
> neither you can audit GOS code with enough confidence to declare that the risk of an exploit or backdoor being introduced is zero.
The updater app is pretty easy to read through. I think a software developer would be able to understand it. The update servers' setups are also very easy to understand. It doesn't take a software developer genius to figure these things out.
My point is that from Rossmann's perspective, being target of the lead GOS software dev hostile behavior as per his "Why I deleted Graphene OS" induces Rossmann's --> perception <-- that the GOS could go after him if he really wanted to. First, everyone is busy and has their life, suggesting that his spend hours going through code and documentation he is not familiar with to make sure he is not target is moot. Most people don't read TOS, and same goes for Licences and docs of OSS. Between doing that and stop using it as it's main device OS, the easier choice is the latter. As a software dev myself, your expectation of layman being able to navigate something like a code review, or even an investigating an exploit is hardly reasonable.
So it is not "incorrect". I am not even saying Rossmann could be targeted. I cannot even make this claim as I have not gone through the docs nor understand the build and update pipeline, which is kind of my point: I can't be bothered neither for GOS, nor for the most of the FOSS software I use. The majority of OSS user rely on the vague concept that motivated and honest people audit the code, but hardly anyone is going deep dive into how an arbitrary piece of software works.
The main issue is the attitude of that GOS developer, whether they like it or not, taints the confidence in the project. it does not matter if Rossmann can or cannot be targeted technically.
The issue here is not technical but a reputation issue.
> The updater app is pretty easy to read through. I think a software developer would be able to understand it. The update servers' setups are also very easy to understand. It doesn't take a software developer genius to figure these things out.
Even then, it could be argued that the rules in place could be changed to introduce malicious exploit if the lead dev(s) were motivated enough. Especially given GOS relatively top-down structure, relying essentially on a benevolent dictator. Even if I made the effort, then ascertain there was no vector attack, now I have to stay on alert every commit / release version and spend as much time looking for a targeted exploit ? etc... Update server setup might be clean, but an admin could SSH or gain access in some way or another and do rogue changes, were they determined enough. The probability is not zero.
Again, the problem is eroding the trust of the specific user (Rossmann in this case).
> Well, he can do everything to your phone, software and data by pushing software updates.
Other developers are doing the bulk of development work these days, so this is nonsense.
> Paranoia could result in just making the system more secure, but why not add a backdoor to find the spies in your userbases that communicate with the black suited men that secretly run our government?
Again with the baseless claims that he's crazy. Your argument here is that "he is crazy, so maybe this happens too." It's nonsense. There are no backdoors, and if there ever were any backdoors, they would be found. GrapheneOS isn't some small project that nobody knows about. It's famous for being very secure, even famous people have said publicly that they use it or others should use it. Cellebrite cannot even hack into it. Backdoors wouldn't go unnoticed. This is also nonsense.
That sums it up perfectly
At the time, Rossmann was mainly using GOS, but due to what he perceived as hostile behavior from GOS toward him through their communication, he opted to stop using GOS (at least on his main device, as he claims).
His rationale was that the behavior of said lead developer was not "rational" and "scary", and since the developer has not only edit access to GOS code but also update publishing infrastructure, Rossmann's data or himself could be targeted through malicious code pushed via an update, for example. While GOS is opensource and malicious code or exploits could be detected by the community, he himself did not have confidence to audit the source code to make sure it was safe, hence his decision to stop using.
By risk factor, I think the grandparent suggests that something similar could happen to someone else using GOS, the risk factor being essentially at the mercy of GOS developer, would they wish to harm said user.
if (user is rossmann) {
// do bad things
makes me think who is paranoid here.
Rossmann himself has no confidence to audit the code, so why take the risk ? Good enough reason to be "paranoid", or at least feel uneasy about it if you ask me.
GOS doesn't use an account, so the code would have to perform very targeted heuristics in order to verify this is Luis' phone. It would have to compare his sim number against a known one, or dig into application data to find his logins and compare them against known emails. So the only way to not write `if (user is rossmann)` would be to send various diagnostics over the wire, to a service that contains these identifiers and perform the comparison onlinr, meaning he would introduce an imense security whole into everyone's phone, and everyone would see there is a home calling.
So it's either a patch of if user == rossmann, or a home calling patch.
I don't have to elaborate techniques. If a determined (and potentially mentally unstable) developer decides to leverage their full control over the OS to make it happen can. I don't have to elaborate on the techniques which might or might not exist yet. Stuxnet only targeted specific Iranian systems, a needle in a hay stack, was spread did not harm random devices across the globe, and stayed mostly undetected. And this was done without "developer access" to the software itself. Is it hard ? Yes. Is it likely (especially given the knowledge of how GOS works) ? Perhaps not. Is it impossible ? Definitely not.
When the lead dev of the OS you use daily threatens to "publicly expose you" as a user, I won't blame said user to stop using the software. And even less, to provide such data point regarding the behavior of that developer.
And if your whole business is a secure OS, it's a very risky proposition: you get caught doing this once, and your reputation is gone forever.
This isn't even possible given how updates on GrapheneOS work. The update client doesn't send identifiers to the update server, and the update server only hosts static files.
Rossmann either doesn't understand this, or he made it up to get more views, or possibly to entertain fellow Kiwi Farms members.
To be honest, I don't think that he didn't understand that he couldn't be targeted. He continued using GrapheneOS for months after the video. As I understand it, it was clear in a few videos months after the initial video was published.
> Rossmann either doesn't understand this, or he made it up to get more views, or possibly to entertain fellow Kiwi Farms members.
Expecting a layman to know that is not reasonable. The argument is not about the GOS updates work in practice. It is about the "perpection", from Rossmann's perspective that the lead dev of the OS is hostile against him. Humans are not purely rational machines, and given the choice of either 1) spend hours auditing source code and updates pipelines (every release ?) and 2) stop using it for critical purpose, the latter is the easier choice, especially for a busy person like him.
> To be honest, I don't think that he didn't understand that he couldn't be targeted. He continued using GrapheneOS for months after the video. As I understand it, it was clear in a few videos months after the initial video was published.
For all we know, he is using it on his secondary device where he has removed what he deems critical. Again, Rossmann NEVER said "don't use Graphene OS", or "Graphene OS lack security" or anything of the sort. If anything, even after that video, he kept recommending GOS whenever he talked about privacy.
His argument is that he did not feel safe knowing using software from a hostile developer; and that he can't be bothered / not qualified to audit the code well enough to make it worth it (which is reasonable if you ask me, and I dare say most people).
Edit: > Rossmann either doesn't understand this Again, I agree with you here. He does not understand. He trusted the developer(s) to know what they are doing, but they broke that trust by being unreasonable, to say the least. He is under no obligation to understand. As for what you stated after that, I won't comment on it as I don't read minds, and pretty sure neither do you.
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.
But he didn't. It's clear in his later videos that he was still using GrapheneOS, I believe even for months after the video.
> Better safe than sorry.
People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files. If Rossmann was really that worried, all he'd have to do is use a VPN. But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Emphasis on "seemed to have stopped using it as his main device". For all we know, he kept it as secondary device (its just that good) after removing anything he deemed critical. Again, he never said "don't use GOS", or "GOS is not secure". He said he was did not feel safe enough because of the hostility from the lead dev.
> People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files. If Rossmann was really that worried, all he'd have to do is use a VPN. But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Does it matter ? Rossmann is a layman when it comes to software. What he perceives is that "lead GOS dev is hostile against me and has essentially full control over the project". First, he is under no obligation to spend hours learning how GOS updates work and audit the code every release, whether or not some identifier is being tracked or not (and by the way, you can still get identified and tracked even if you use a VPN). The damage was done once that lead GOS dev persist in toxic behavior, for the lack of a better word.
> But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Unsubstantiated claims. We cannot read his mind, and I have yet to see any evidence that would support these.
Sure, but that requires additional data about the user, which the GrapheneOS update server doesn't get. Both the update client and the update server are open source, so you can verify any of what I'm saying. The server only sees the user's IP address, which device model they're requesting an update for, and which update channel (alpha/beta/stable) they are using. The HTTP headers, etc. for the request would be identical across any GrapheneOS device, as they use the exact same updater app.
https://github.com/GrapheneOS/releases.grapheneos.org https://github.com/GrapheneOS/platform_packages_apps_Updater
> First, he is under no obligation to spend hours learning how GOS updates
That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.
Again, that is beyond the point. The developer going rogue (for arbitrary reason) and turning the code malicious is not impossible.
> That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
All of you who keep commenting "But it's so easy, just look it up" are lacking consideration and empathy. Other people don't think like you, they don't have to think like you. Just the documentation you have linked has so many technical terms, someone not familiar with networking and system design will barely make any sense of it.
It is a also a matter of trust. After the developer express their hostility multiple time, even if someone was willing to go through it, what if the documentation is not forth coming ? It is within the devs control after all. How does one even make sure that the software does what the documentation says it does ? etc...
> But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.
What "absurd" claim did he put out exactly ? His issue was never about the technical aspects of GOS. It was about the broken trust and the perception that using software from a hostile developer was a risk factor, hence his stopping using it (at least on his devices with sensitive info).
I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation. I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion. It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
> What "absurd" claim did he put out exactly ?
His speculation about targeted malware in the OS.
This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
"Baseless" could not be further away from the truth. You literally have the GOS developer messages coming in live while he rehashes frivolous accusations and threatening to exposing him. To claim objectivity, when you seem to cherry pick the parts of the video that would (loosely) fit your narrative. Where is your evidence that Rossmann is in anyway associated to harassment campaign against the project ?
> This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
Damn, so close, you were almost there. A more accurate analogy you could have come up with, had you actually critically listened to Rossmann's argument in his video. Yes, it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you. At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code. It might be unlikely given what we know about software dev, but it is not impossible, and for Rossmann, that is the only thing that matters at the end of the day.
Moreover, the GOS dev himself clearly stated he would "publicly expose him" (At 2:14 in https://youtu.be/4To-F6W1NT0?t=134 "and there will be information published about your (Rossmann) attacks on me in support of an abusive person). Why the double standard ? That GOS dev can go around dishing out "reputational harm" but his targets doing the same is not fair game ?
At this point, Rossmann did him a service by publishing everything himself. As far as any reputational harm is concerned, the GOS developer essentially brought it on himself. Could have dropped back when they had the fallout in September 2022, as per the chat logs (<https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>) ...
> I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion.
Sure, "harm the reputation of the project" when he was proactively giving them no string attached grants, spreading the word, and giving them an opportunities to tell their side of the story ...
> I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation.
Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
> People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files...
We are literally talking about an OS here. It has an almost total control over your phone - what does it matter if the updates can be targeted? The GOS could snoop on their users and turn into malware only if it figures out that this is Rossmann's phone.
This is what is keeping me from installing GOS too. Interaction from the developers seems very aggressive towards the competing OSs, which doesn't inspire much trust. Who is reviewing the GOS changes? Are they really all benign? In the end you need to trust someone, but I'm not sure GOS is more trustworthy than LineageOS (which has a bigger community, more developers and /e/os building on top of them).
Happy to be convinced otherwise.
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!
Your CopperheadOS description is one perspective, one that does not look all that believable now after his mental illness became clear.
I did not share the video, but I would and it is not clickbait.
I will not further respond to you, I don't think this would lead to a fruitful discussion. Kindly think about what kind of trust is necessary to trust in the proper functioning of a device as personal as a modern phone, and think about attack scenarios that could occur when the main developer of your OS is not trustworthy in the slightest.
Here you are again in yet another comment repeating these baseless claims about mental illness.
> think about attack scenarios that could occur when the main developer of your OS is not trustworthy in the slightest.
First of all, he's not the main developer. There are multiple developers. The other developers do most of the development work these days.
But to say that the OS is untrustworthy is completely false. You say GrapheneOS's founder has a mental illness based on watching a video where someone turned malicious toward the project recorded a conversation where the founder was extremely upset after being swatted multiple times.
The update client doesn't send identifiers when checking for updates, and the update servers only have static files saved to them. You're making stuff up here, and clearly trying to turn people off of using GrapheneOS by repeating baseless claims that the founder is crazy and fake worries of being targeted by them.
> 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.
> Of course he was upset when Rossmann showed his true colors
I saw the chats. You lie. Showing his true colors = not accepting that there is an evil conspiracy and asking for proof. You are completely brainwashed and I will not continue this discussion.
If Calyx is not the next best alternative be invited to link to what you think is the best alternative. I still think it's Calyx.
You provided exactly 0 sources in all of the comments I've seen posted by you so far.
> Showing his true colors = not accepting that there is an evil conspiracy and asking for proof.
"Evil conspiracy"? You say that someone else is paranoid and yet you are saying things like this? It's kind of ironic.
> You are completely brainwashed
Okay. If you say so.
It has they initial conversation and disagreement in September 2022, after the GOS developer in question accuses Rossmann of being complicit with harassment campaigns again said dev., because he also gave the same 40K USD FUTO grant to other similar project and had some interview with their developers.
The second set of files are the text messages that feature in the video, after said GOS developer contacted Rossmann umprompted on May 2023 with the same type of accusation.
Feel free to peruse and make you own opinion.
All I said is sourced.
The people you've had respond to you in this thread, who likely have more intimate knowledge of what actually happened, have done a better job of breaking down this stuff - so I'll just defer to them.
For more context, there was a Google Drive link that is unfortunately not available anymore, but I found and uploaded it here: <https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
It has they initial conversation and disagreement in September 2022, after the GOS developer in question accuses Rossmann of being complicit with harassment campaigns again said dev., because he also gave the same 40K USD FUTO grant to other similar project and had some interview with their developers.
The second set of files are the text messages that feature in the video, after said GOS developer contacted Rossmann umprompted on May 2023 with the same type of accusation.
Feel free to peruse and make you own opinion.
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.
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.
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?
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).
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?
From what I have observed, nobody is held to account when there is a software issue, commercial or open source.
At least graphene wouldn't be expected to shield the perpetrator.
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...
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.
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.
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.
I think the main problem is that people can be affected that aren't even using it, which is why it is such a big problem. You can't really hide it's GrapheneOS either, even just by virtue of the features available on the device, you'll be able to deduce what it is.
I understand the idea behind it but it simply isn't realistic to provide and can put people in danger - the very thing it's meant to prevent.
When I say hide, again for 99% of the people. Splash screen, setting spoofing. Sometimes good enough is better than perfect.
And even if the attacker can see the other profile you can just say was your friend’s profile and it’s lost.
Or better, not sure if possible: export the profile in a file like veracrypt. Then when you need the profile import from this file and would restore the secret profile.
It's not about criminals. It's about the police, government spy agencies, and other knowledgeable threat actors.
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...
We're of the opinion that there's a growing portion of the population that is becoming more security and privacy conscious, and that's reflected in our userbase, which has been growing consistently over the last few years.
We're not saying we're going to have iPhone's marketshare, but we're constantly growing.
>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.
Yes, but at that point, the data is irreversibly rendered inaccessible. There are situations where the data itself is the most important factor, and where the owner of the device being hurt doesn't benefit the adversary now that the data is gone. Of course, as with everything, it depends on one's situation, but the duress PIN feature doesn't involve trickery. It's a way to reliably and quickly do a very specific thing.
Oh god, yes. Please! I can't wait to leave the walled fruit garden, but can't tolerate Google sniffing everything I do or do not do on my phone either.
PS. I just hope it's an OEM that sells devices to a lot of countries including developing ones and not something like Fairphone.
For a corporate using an OS in work phones. The threat model is state/corp-sponsored actors. Trade secret leak is unacceptable. When in doubt, data should be wiped. Now wiping PIN makes total sense and is the only sensible option.
An ordinary person, on the other hand, often deals with non tech-savvy ordinary people. The threat model is different. Most likely plausible deniability is enough. The threat level is low. Those users may accept to trade some data security for a more friendly feature.
The ultimate question is whether Graphene envisions itself an opinionated OS that always follows the "best practice" or a generic OS that allows users to define their own threat models.
> we're currently working with an OEM to have their devices have official GrapheneOS support.
There was a youtuber who got kidnapped in Haiti a while back, and his kidnappers demanded to search the photo gallery on his phone for something. So what he did was delete the pictures, but not empty the trash, hoping they wouldn't know about that feature. They didnt, and he got away with it. Did Apple envision a kidnapping scenario when they were designing that feature? Probably not. Is there a design lesson that can be taken from that situation? Also probably not, because it just as easily could have gone the other way.
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.
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.
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?
Subscribe to comp.mobile.android. Sadly there's no libre client yet, but Mozilla might release a Thunderbird version with NNTP support.
Cops say criminals use a Google Pixel with GrapheneOS – I say that's freedom
https://news.ycombinator.com/item?id=44658908
Cops in [Spain] think everyone using a Google Pixel must be a drug dealer
https://news.ycombinator.com/item?id=44473694
ICEBlock, an iOS Exclusive
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 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.
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.
However one must note also that for now not even Snapdragon fulfills GOS requirements. If/when that changes, Snapdragon devices may have more open-source community momentum than Google's Tensor. Plus all the economy of scale, etc..
In terms of security, Microtek is even more far behind Snapdragon.
Again, not an Android dev here, take the text above with a grain of salt, YMMV, etc..
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)
I like being able to reach across the keyboard one-handed (to shift, etc) and I can't do that on modern, larger phones.
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.
Ahaha, don't get your hopes up, friend. The possibility of an adequate, degoogled Android with picky requirements as GOS on good, ultramobile hardware (matte DCI-P3 IPS, 3.5 mm audio, USB-C 3.2 or better, dedicated, ideally quick-access mSD card slot, IP68 rating, good cameras, EMR pen compatibility, changeable battery, non-plastic case) is virtually nil. That would essentially be a modern hybrid between a Samsung XCover Pro 6 and one of the older Samsung Note phones, e. g. the Note 9. Days long gone... :(
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!
A collaboration with an OEM doesn't mean we'll stop providing existing or future Pixels if they continue to meet our requirements.
Pixels will be supported until end-of-life. Future Pixels will be supported if they continue meeting our requirements.
> 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 ?
We expect 10th gen Pixels to meet our requirements and we should be able to add support for them. It's not going to happen in 12 to 48 hours from the official launch of the devices as we did for around the Pixel 6a and later. It will be more work. We've automated most of the device support for existing Pixels now and have removed nearly all of the Android 15 QPR2 device trees rather than manually updating them. We're continuing to automate more and will use that approach for supporting new Pixels.
The devices with an OEM partner are further in the future than the Pixel 10. We need Qualcomm's new SoC with hardware memory tagging support to launch because a flagship Snapdragon is the best fit other than the current lack of hardware memory tagging. Some things need to be addressed by the OEM including licensing extra things like Qualcomm and filling in some missing features. There needs to be a clear, workable plan for updates including Linux kernel LTS branches.
"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-...
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.
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.
Our recommended devices can be found here:
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.
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.
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).
So then what's the point of having a Play Store without Google Play services?
Signal brings its own notifications, so they work perfectly.
The only app which was broken to the point of unusability was Too Good To Go, which demands that you pick locations on a map which relies on Play Services; the manual city entry is broken.
I use Google Maps only in Firefox Focus, but I've heard that builds of Google Maps up to about a year or so ago didn't rely on Play Services, and with Aurora Store you can manually enter a build number to install.
tl;dr: 10/10, fabulous experience.
Install Droidify, enable the repos, and install "microG Services" and "microG Companion".
I am personally more than okay with using the official, proprietary GP services from time to time if they abide by the same rules, especially that I can make these rules as strict as I want.
And even if you install Google play on your graphene phone, it is still more isolated by default. Add that to the concept of storage scopes and more permissions control (apps have to ask for access to the network) and you have a more secure platform.
After opening the application, it complains about being installed through an "insecure method", and bails. Reinstalling through Google Play magically fixes that.
These "security checks" are spreading like measles, so expect to see this sooner or later.
That's because apps that aren't published just on the Play Store but also on other stores or for direct sideloads (for users running Huawei for example which doesn't have Play Store) need to be able to detect the installation method to do updates on their own if there is no backing store.
It's the responsible thing to do. Apple has done it a few times.
I recommend putting proprietary Play Store apps grabbed with Aurora Store in the work profile with Shelter[5].
[1] https://obtainium.imranr.dev/
[3] https://f-droid.org/packages/com.aurora.store/
[4] https://f-droid.org/packages/de.marmaro.krt.ffupdater/
Also "private space" is now available with Android 15 and can provide the same separation within a single user profile.
Different use cases. User profiles are only active when you manually switch to them, while work profiles are active _alongside_ your main profile.
So for untrusted apps that you only use occasionally and on-demand (like the myriads of travel / shopping / random services apps), user profiles are great. For apps that you want to keep in the background, such as the proprietary messaging apps that all your friends use, a work profile is much nicer.
GrapheneOS supports having a Private Space in secondary users instead of only a single one in Owner. Supporting multiple Private Spaces per user is a planned feature at which point work profiles will be fully obsolete. The remaining use case for work profiles is to have both a Private Space and work profile in the Owner user.
> It doesn't matter that the app is trustworthy, because F-Droid are extremely incompetent with security and the apps you install from F-Droid are signed by F-Droid rather than the developer.
https://discuss.grapheneos.org/d/20212-f-droid-security-in-s... https://discuss.grapheneos.org/d/18731-f-droid-vulnerability...
They also say, if you use F-Droid, at least use F-Droid Basic:
> Dont use the main F-Droid client. Android is pretty strict about SDK versions and as F-Droid targets legacy devices, it is very outdated.
https://discuss.grapheneos.org/d/11439-f-droid-vsor-droid-if...
> If the app is only available on F-Droid / third party F-Droid repo, use F-Droid Basic and use the third party repo rather than the main repo if available. > > If the app is available on Github then install the APK first from Github then auto-update it using Obtanium. Be sure to check the hash using AppVerifier which can be installed from Accrescent (available on the GrapheneOS app store).
https://discuss.grapheneos.org/d/16589-obtainium-f-droid-bas...
By the way, while GrapheneOS recommends Accrescent, I don't use it anymore because they can't even add apps like CoMaps, while some of the apps they actually added are proprietary.
That doesn't seem like a con if you take into account the context: F-droid is not shipping pre-build binaries from the developper, it asks for a buildable project from the developper.
If the source repo of the upstream dev are compromised, so will be hid own binaries anyway.
Having recently gone through the F-Droid release process, I learned that this is not necessarily the case anymore.
F-Droid implements the reproducible builds concept. They re-build the developer's app, compare the resulting binary sans signature block, and if it matches they distribute the developer-signed binary instead of their re-built binary.
This is opt-in for developers so not all apps do it this way. I'd sure like to know how common this is, I wonder if there are any statistics.
The process adds a significant delay for updates but it does not actually protect users from developers in any meaningful way. This real world example with WireGuard demonstrates that.
What kind of issues did you have? I think it does require google play services (which can be installed easily).
I have used GOS on a pixel 6 for the past two years with no issues. The phone finally died on me last weekend, so I'm in the market for a new pixel which will be getting GOS right away.
Check if yours is on the list.
In Sweden we typically use Swish, which again works great.
"Tap to pay" things are problematic though but it's not something I personally use (even before I migrated away from stock Android).
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.
- it’s a lie
- not even a white lie, they know perfectly well, that they can do way more
- most of the security “features” are completely useless
- they also know this
However, it’s very difficult to prove these, and laymen don’t and won’t understand the details.
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.
I am alright with things that allow for improvement, at least in theory
SailfishOS is not open source itself. It's far less open source than Android which has the Android Open Source Project with the whole base OS.
That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
Sadly this was, to your usual points, at the major expense of security making those devices purely research projects at best and not something anyone should ever actually use.
When you are stuck on a platform that requires closed firmware you are kind of stuck blindly accepting updates from the vendor to patch security bugs, stuck hoping they are not actually introducing new backdoors.
This is why I reject platforms that require closed firmware in the first place to the fullest extent I can.
Even more FOSS friendly graphics vendors like AMD and Intel rely on binary firmware.
With the right hardware choices running blob-free linux is pretty straightforward.
Which Nvidia card do you have, and at which clock speed does your GPU run?
> With the right hardware choices running blob-free linux is pretty straightforward.
Unfortunately no. Features like SSE are pretty amazing and have made CPUs really fast and efficient, but they're unfortunately also large attack vectors, so vulnerabilities like Spectre or Meltdown occur. You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
If you are not running games (which you should not on a system you need to be able to trust) maximum clock speed from a modern GPU is not needed for most workstation applications.
I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
> You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
Really? Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?
I make different tradeoffs on different hardware to be sure depending on the threat model of the task I am working on. x86_64 is a bit of a shit show, but you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else.
Do you count binary firmware as 'open' or not? If not, AMD is not 'open' either. If you do, Nvidia now also has open kernel drivers. Mesa developers are exploring ways to get the new Mesa Nvidia Vulkan driver (NVK) to run on top of the open Nvidia kernel driver, which should eventually make Nvidia drivers as open as AMD.
I generally only run gaming graphics cards on dedicated gaming machines, not on workstations I need to be able to trust. You can't use accelerated graphics in qubes anyway, specifically because graphics cards are hard to trust.
My requirements from a workstation are:
1. MUST have 100% open source code loaded in system memory
2. SHOULD have open source software in the boot trust path (coreboot/tpm2 secure boot, etc)
3. SHOULD have open hardware to the furthest extent possible that meets my use case
4. SHOULD be fully auditable and tamper evident using at-home tools and methods (like the Precursor)
Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.
> I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
Yeah I agree on that, I also purchase AMD cards exclusively now.
> Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation
I assumed we were only talking about x86. But I also believe that POWER9 CPUs don't have SSE, prove me wrong. I guess you're running Linux? I'd be very interested in looking at the output of lscpu from one of these machines.
> x86_64 is a bit of a shit show
I fully agree there
Yeah I only use dead simple workstation cards or integrated graphics on my workstations, and AMD GPUs on my gaming systems which I don't trust at all (but still prefer to support companies that use open drivers)
> But I also believe that POWER9 CPUs don't have SSE, prove me wrong.
POWER9 has its own SIMD system (AltiVec/VMX/VSX) instead of SSE which is entirely its own thing. I have no idea of the performance tradeoffs here though for various use cases, as freedom is biggest factor for me.
> I'd be very interested in looking at the output of lscpu from one of these machines.
Here is an lscpu from an 8 core Blackbird though it will probably render poorly on HN.
Architecture: ppc64le Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Model name: POWER9, altivec supported Model: 2.3 (pvr 004e 1203) Thread(s) per core: 4 Core(s) per socket: 8 Socket(s): 1 Frequency boost: enabled CPU(s) scaling MHz: 58% CPU max MHz: 3800.0000 CPU min MHz: 2166.0000 Caches (sum of all): L1d: 256 KiB (8 instances) L1i: 256 KiB (8 instances) L2: 4 MiB (8 instances) L3: 80 MiB (8 instances) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-31 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Mitigation; RFI Flush, L1D private per thread Mds: Not affected Meltdown: Mitigation; RFI Flush, L1D private per thread Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Not affected Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation b arrier enabled Spectre v2: Mitigation; Software count cache flush (hardware accelerated ), Software link stack flush Srbds: Not affected Tsx async abort: Not affected
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...
As opposed to "being free in all senses of the word", which is what the comment was talking about.
And now you're running a two year old phone and it's effectively obsolete.
If they would just upstream their firmware into the Linux kernel, you could upgrade these phones for years and years. Until the hardware is actually physically incapable of running the latest features.
Some vendors, like Google, promise to provide updates for a long time. But it's just that - a promise. There's no technical guarantee or mechanism for this, it's purely based on trust.
The Precursor is promising, but software is not there yet.
I sit down at my desktop computer and send emails and type messages like this one. Then I get up from my desk and spend time with my family offline and present. It's pretty great.
It would be nice if the firmware itself was free software so that it could be shipped alongside the Linux kernel, maintained indefinitely and we could customize it however we want. The hardware is supposed to do what we want it to do, not what the manufacturer lets us do.
I don't like the fact every single device out there has entirely separate computers inside them running unknown proprietary software. It feels like our operating systems aren't operating the system anymore, it's like they're just some user app sandboxed away from the real system. This presentation explains what I mean:
It's an imperfect reality. Security by isolation of devices via IOMMU addresses real concerns such as devices being able to access RAM via DMA. It's great that GrapheneOS is doing this.
The Precursor is the only pocket computer platform that is maximally open hardware, software, and firmware but you revert back to the 90s in terms of power as a consequence with alpha quality software today. If Bunnie is successful with his IRIS approach and making custom home-user-inspectable ASICS then maybe a middle ground path can be forged in the next few years.
For now the only modern computing experience with fully open hardware and software I am aware of are the ppc64le based devices by Raptor Engineering, but at a very high cost due to low demand, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
For those that want this story to get better, please buy and promote the products of the few people trying to break us out of dependence on proprietary platforms.
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".
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.
It comes with some minor usability issues with captive Wifi portals sometimes, but the trade-off of not having ads in app or while browsing is way worth it IMHO.
It looks like there's an app on F-Droid called "Rethink" that promises to do both firewalling, DNS blocking, and offers a WireGuard VPN. That seems promising, though I must add that I haven't tested it myself.
On the other hand, the functionality is top notch. Easily the best integration of consumer level DNS + firewall blocking in any application on any platform. Just block everything of an application by default and then watch the connection logs for the app and start unblocking stuff via ips, domains or wildcards until the app starts working again.
You can use Google apps and apps depending on them on GrapheneOS via sandboxed Google Play. The vast majority of Android apps can be used. You don't need to stop using Google apps/services or other mainstream apps to use GrapheneOS. It's likely nearly all the apps you use or even all of them work on GrapheneOS. There's a per-app exploit protection compatibility mode toggle (and finer-grained toggles) to work around buggy apps with memory corruption bugs. We avoid turning on features breaking non-buggy apps by default and hardware memory tagging is temporarily opt-in for user installed apps not marked as compatible due to how many memory corruption bugs it finds.
A small number of apps are unavailable due to checking for a Google certified device/OS via the Play Integrity API. These are mostly banking apps, but most banking apps do work on GrapheneOS. There are tap-to-pay implementations which can be used on GrapheneOS in the UK and European Economic Area. Several banking apps recently explicitly added support for GrapheneOS via hardware-based attestation as an alternative to the Play Integrity API. We're pushing for more apps to do this and for regulation disallowing Google from providing an API to app developers for enforcing devices licensing Google Mobile Services. Play Integrity API often portrayed as a security feature but Google chooses not to enforce a security patch level. They're permitting devices with years of missing important privacy and security patches but not a much more private and secure OS. Only their strong integrity level has a patch level check, but the check is only done for recent Android versions and only requires they aren't more than 12 months behind on patches which serves no real purpose.
> you can also root/firewall on normal android
This is different from our Network permission which not only blocks direct access but also indirect access via APIs requiring Android's low-level INTERNET permission. Our Network permission also pretends the network is down through many of the APIs. For example, scheduled jobs set to depend on internet access won't run.
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.
It's basically only useful for debugging.
If you want it to stay free
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.
[1] https://discuss.grapheneos.org/d/475-wallet-google-pay/4
Chromium still is the superior browser in terms of security and Firefox is way behind. Adding an extension so you _might_ have less security exploits in the foundation is a wrong tactic and should be avoided.
[0] https://grapheneos.org/features#vanadium
[1] https://github.com/gorhill/uBlock?tab=readme-ov-file#ublock-...
During a call, drag your buttons and they will scroll. The call recorder is the 7th button.
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.
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.
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.
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.
> 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.
See note at the bottom here: https://github.com/microg/GmsCore/wiki/Installation
I stand corrected. Do you have plans to switch to BeaconDB when the coverage in the USA improves?
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.
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".
We also expect Google's Play Integrity API to inevitably be ruled as anti-competitive, which it is.
> We also expect Google's Play Integrity API to inevitably be ruled as anti-competitive, which it is.
I certainly hope so.
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
Fossify is a FOSS project with a handful of volunteers and they do take donations:
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)
You might want to try:
- writing the city name at the beginning
- putting the street number at the end
Note that OSM might not have the street number. If it doesn't, searching for it will fail for sure.
You should probably file an issue: https://codeberg.org/comaps/comaps/issues
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.
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
JuiceSSH is still under development?
>Vivaldi: power-user's browser
Propietary. Get Fennec with FDroid with Ublock Origin and some addons.
StreetComplete: help update CoMaps and OpenStreetMap
Catima: for loyalty cards
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.
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.
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.
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 uiCan 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!
https://grapheneos.org/faq#device-support:~:text=The%20follo....
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...
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.
This does not make sense at all.
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.
Smartphones are small portable computers. You're using a similar computer to make posts on social media platforms including Hacker News.
> It is better in one way: a reasonably stable person holds the keys to the kingdom.
Repeatedly claiming that I'm insane, schizophrenic, delusional, etc. is not a reasonable criticism of GrapheneOS. I'm clearly none of those things. I've been targeted with attacks including harassment and tons of fabricated stories for years beginning with my former business partner and his associates. You thoroughly discredit yourself by going as far as baselessly claiming that I'm schizophrenic because you don't like the way I've tried to defend myself from these attacks.
The lead developer of CalyxOS (cdesai) was a Copperhead employee directly involved in the 2018 takeover attempt on GrapheneOS. CalyxOS itself directly originates from the takeover attempt on GrapheneOS. The people involved demonstrated their lack of ethics through their participation in the attacks on GrapheneOS and partnerships with people involved in it. You've been attacking us for years alongside them. CalyxOS exists because of this takeover attempt. It's a non-hardened OS which was created by heavily using GrapheneOS source code and documentation without most of our privacy and security features.
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.
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.
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.
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.
No, not really, and there's no reason those can't run AOSP.
> MNT Reform
It has a typical closed source ARM SoC and other components. The chassis and board being open doesn't make all the components open. CPU, GPU, MMU, USB, etc. are provided by the SoC and are closed source as usual. It has closed source hardware and firmware for the SoC along with other closed source hardware and firmware. Not having to load firmware from the OS does not mean it's open hardware and firmware. It's barely more open than other computers for the most complex parts of it.
How is something fully open hardware if the vast majority of the complexity is in closed source components providing most of the functionality? The SoC is just the most complex of these by far.
Why couldn't AOSP be run on a regular ARM SoC used in devices which run AOSP? AOSP works fine on top of the mainline Linux kernel and drivers.
> Talos II
A mostly open source motherboard where you drop in a closed source CPU is not really an open source platform. It's not fully open source itself and the CPUs used with it are not open source. IBM took steps towards open sourcing PowerPC as an ISA and relatively primitive open source cores OpenPOWER core designs exist. However, what's actually available and used with it are closed source CPUs. In theory, there can be open design CPUs for use with it. As a motherboard, it's pretty close to fully open hardware. As a functioning computer, it's mostly not because a motherboard is not a whole computer and is far less complex than the CPU even with a more traditional desktop design with less functionality moved into an SoC.
> Precursor
It has a closed source FPGA as the primary processor and other closed source components. It's far closer to being open source, but it isn't fully open hardware. This is the only one you listed which is anywhere close to mostly open source. It is very far from a powerful modern smartphone device though.
> Those are lightyears ahead in openess and auditability compared to anything Google produces.
The primary SoC in each is closed source. Precursor programs their CPU on top of that closed source FPGA so the CPU is open source in that sense and much closer to being mostly open. It's not the only closed source part of it.
The other 2 examples have a closed source SoC. One uses a regular closed source ARM SoC incorporating far more than a CPU and GPU into the closed source chip. The other depends on a more traditional desktop style closed source CPU from IBM outsourcing more to the motherboard.
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.
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.
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.
They hear their favorite influencer spout something, and they parrot it everywhere. Google bad, hurr durr.
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.
The baseband firmware is not obfuscated and people can/do analyze the cellular protocol and how it functions. Which devices receive more privacy/security research than Pixels do? Which devices avoid trusting multiple companies making the hardware? Nothing. Similar things could be said about any hardware we supported, but all the other available options supporting using another OS would be far less secure and unable to provide what GrapheneOS offers. Core features would be missing elsewhere.
We're working with an OEM to have their future devices meet our requirements and provide official GrapheneOS support, but how would that change anything? It's another big tech company making devices. What do you think is special about Google and what reason is there to think they would be putting a backdoor but other companies wouldn't?
> I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
Isolation for the radios is a standard security practice on most modern smartphones. GrapheneOS improves the security of the isolation through hardening the drivers and services against exploitation after exploiting the radio firmware.
> 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.
The CPU, GPU and many other components in laptops, desktops, tablets and smartphones are closed source hardware with closed source firmware. Wi-Fi and Bluetooth are implemented with a separate processor and operating system. There's nothing about that specific to cellular and it's a misconception that it's different from other components in this regard. Modern computers have a bunch of processors and little operating systems across a bunch of components. Many people have the wrong idea that it's somehow specific to a few things like AMD PSP, Intel ME or cellular radios when in reality that's just how things are at a hardware level across many components. Cellular radios are normally an isolated component.
Cellular can be used to detect location, but so can Wi-Fi and Bluetooth. Wi-Fi is the main way network-based location works. Most Wi-Fi networks are from ISP routers and some even have an official way for other subscribers to use it.
Cellular doesn't need to be left enabled all the time. There's airplane mode. Using cellular is an option. GrapheneOS runs on portable computers with support for Wi-Fi, USB ethernet, etc. too not onlyg cellular.
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.
This isn't really a practical way of doing it. Google Play and Google Play Services having privileged access is more than sufficient.
They write about their reasoning and criteria for device support here, for example: https://grapheneos.org/faq#future-device.
Linking is fine, as you did here: https://news.ycombinator.com/item?id=44686876.
Not "pixel compact", but the size of an iPhone mini.
What about Graphene ? Can I get 5 years of updates without needing to wipe the phone ?
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.
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.
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
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?
https://grapheneos.org/articles/attestation-compatibility-gu...
- 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.
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.
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.
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...
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.
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?
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 only mentioned NFC because you mentioned Google Pay.
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.
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.
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?
The only real option for privacy and security which isn't swiss cheese.
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.
> 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.
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 think the Pixel Tablet was a matter of a week or two.
There seems to be two challenges though that popped their nasty head lately. Some developer being temporarily unaivalable due to personal issue, and something about Android Open Source Project (GOS is built upon it, to put it simply) not necessarily support upcoming Pixels.
But the team seems resilient and motiviated to keep the project going.
> 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.
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.
all of the privacy and security parts of the UX are good, though.
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.
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.
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. [.................]
ranger_danger•1d ago
sigmar•23h ago
TheCraiggers•23h ago
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.
bjackman•23h ago
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?
perching_aix•23h ago
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.
bjackman•18h ago
With SEV-SNP and Intel TDX I think it's possible to build a hardware platform that doesn't require the user to trust the OEM although they still need to trust at least one large American tech company that controls the root of trust.
But I don't think this is ever gonna happen for consumer devices. AFAIK it's only sorta kinda happened for any real-world platforms at all (but maybe someone can correct me).
Ultimately if your threat model includes Google as a potential adversary, and you are not in control of nuclear weapons, you are gonna have to make some serious sacrifices to achieve security IMO. Smartphones are out. (Actually, I guess if you trust China you have a way forward).
XMPPwocky•23h ago
TheCraiggers•23h ago
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.
transpute•23h ago
Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.
JacobThreeThree•22h ago