Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.
Instead, I installed CalyxOS and have been using it over a year now and I'm very happy with it. Check it out.
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.
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. :)
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.
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.
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...
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.
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).
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.
Cops say criminals use a Google Pixel with GrapheneOS – I say that's freedom
Cops in [Spain] think everyone using a Google Pixel must be a drug dealer
ICEBlock, an iOS Exclusive
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.
I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!
[0]: >>44259921
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...
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.
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.
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)
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.
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.
[1] https://discuss.grapheneos.org/d/475-wallet-google-pay/4
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/
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.
Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference >>44586723 )
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)
Check if yours is on the list.
They write about their reasoning and criteria for device support here, for example: https://grapheneos.org/faq#future-device.
> 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.
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...
https://grapheneos.org/articles/attestation-compatibility-gu...
> 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.
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
See note at the bottom here: https://github.com/microg/GmsCore/wiki/Installation
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.
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.
"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-...
https://grapheneos.org/faq#device-support:~:text=The%20follo....
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.
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
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).
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.
Our recommended devices can be found here:
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.
Subscribe to comp.mobile.android. Sadly there's no libre client yet, but Mozilla might release a Thunderbird version with NNTP support.
[0] https://grapheneos.org/features#vanadium
[1] https://github.com/gorhill/uBlock?tab=readme-ov-file#ublock-...
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?
"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" ?
Linking is fine, as you did here: >>44686876 .
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. [.................]
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.
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.
> 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.
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.
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.
https://old.reddit.com/r/StallmanWasRight/comments/1l8rhon/a...
It's not appropriate for you to be saying these things.
> 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.
This makes no sense. GrapheneOS is an open source project and anyone can look at the changes made by the project. Even the OS is reproducible and people do check that, apparently, so GrapheneOS would be caught if they were making changes. Like I even found this repository just now after a quick search https://github.com/lucasbeiler/reproducible-builds-grapheneo...
GrapheneOS isn't just some random OS that nobody has heard of. There are lots of eyes on it, so sneaking some backdoor into the OS would be very difficult and extremely stupid. One misstep and the project would be gone. Do you really think Rossmann is worth that? I don't.
> 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.
I've already pointed out in other comments that he had no good reason to fear a targeted update. It's just not possible. He should know that by now, but as far as I know he has never retracted that part of his video.
Well, yes, but not really. What you're saying could be true if the OS wasn't open source. It's not some small OS that nobody knows about. There are forks of the OS, there are other projects that selectively copy code/commits from GrapheneOS, there are security researchers who pay attention to its development. There are also people who reproduce and verify builds. It's just not possible for that kind of code to be snuck in there.
This section of the website about whether GrapheneOS is audited is also helpful https://grapheneos.org/faq#audit
> 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.
If you pay attention to what they're responding to, you'll find that a lot of that is in response to something they said, clarification about inaccuracies in news articles, etc. The official accounts are also followed by many of the OSes' users, so some posts are for them too if certain things are being talked about in the community.
> 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).
I personally prefer quality over quantity. GrapheneOS developers take a long time to develop new features, test them, rewrite them, and it goes on and on until they have a resulting feature that is very high quality. They also have to keep in mind how much they're adding/changing so features and changes can be ported quickly when there are new upstream releases. Updating quickly is very important for security. Leaving vulnerabilities unpatched for months is not acceptable for a project and users who value security. The same can't be said of LineageOS or /e/OS. They're slow to update, roll back security, etc.
> GrapheneOS Foundation was created as a non-profit organization in Canada in March 2023 to handle the intake and distribution of donations. [1]
> GrapheneOS Foundation has been incorporated as a federal non-profit organization in Canada. It will be used to receive donations to pay developers and pay for infrastructure. It will also help to shield developers from attacks through the legal systems across various countries. [2]
There is no cause for concern necessarily. These are design choices, nothing more.
Users have no idea what happens to the data that leaves their computers. To quote from another story currently on the HN front page: "It's incredibly easy to give information away. But once that data is out there, it's nearly impossible to take back." >>44689059
Promises made by developers are reassuring to some, but rarely if ever legally enforceable in the event something goes wrong, and the harm already caused may be beyond redress. As a proactive measure users can, among other things, seek to minimise the amount of data they send. For example, some users might want the _option_ to stop their phones from constantly trying to ping or connect to remote servers _without any explicit user intent to do so_. Maybe they do not want their phone to act like a beacon to someone else's remote server.
The point of the comment is that sometimes there are remote connections being made to servers chosen by developers that are assumed to be OK with all users, e.g., connections to Graphene servers, IPinfo servers, or myriad other examples. Meanwhile there is no option for the user to disable this behaviour. There may be some users who prefer _zero_ remote connections except the ones they themselves choose to initiate or enable. The possibility of such users often seems to be overlooked or deliberately ignored.
Like Firefox constantly sending HTTP requests to remote servers to check for "connectivity". Even when the user is not trying to connect to any server. The requests are sent in the clear. This is not optional behaviour.
Par for the course with GrapheneOS. They always seem to take a good thing said about them and not be satisfied.
Chromium has vastly superior security compared to Firefox. https://madaidans-insecurities.github.io/firefox-chromium.ht...
> It tries to copy Google paternalism > > It swaps a Google mothership for a Graphene mothership
Nonsense claims. All network connections made by the OS are well documented on the official website: https://grapheneos.org/faq#default-connections
There are only a few services GrapheneOS devices connect to:
- a time server (securely, over HTTPS, not insecure NTP)
- the OS update server (obvious; it's just plain HTTP requests, no user identifiers other than the IP address, which can easily be masked by using Tor or a VPN)
- the GrapheneOS App repository, which provides updates for preinstalled apps like Auditor, as well as the Vanadium browser and WebView (it's critical to get security patches for your browser in a timely manner)
- network connectivity checks (required to sign in to public wifis that use captive portals; can be entirely disabled in the settings)
- SUPL and PSDS through GrapheneOS proxies for A-GNSS because there is no network location service enabled by default
> Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
You can block all the connections. You don't even need to, since they can all be disabled in the settings. If you disable the System Updater app, you're gonna have to adb sideload your system updates https://grapheneos.org/usage#updates-sideloading.
> If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
You don't need Netguard, GrapheneOS has a built in network permission toggle, which offers even better protection than a firewall, since it completely blocks access to the underlying network socket (https://grapheneos.org/features#network-permission-toggle)
> The user-hostile design of Android is that apps keep running in the background after they are "closed"
You can deny apps running in the background, even on stock Android. This isn't unique to Android btw, I'm sure you've come across the system tray in Windows before. Those are all apps running in the background. Android basically has the same thing, it's in the notification center, and you can also stop background apps from there.
GrapheneOS definitely doesn't use it. It doesn't contact any third-party APIs. Everything is well documented: https://grapheneos.org/faq#default-connections
In both cases, they could opt to download our database locally and use it through their own API system.
We sponsor the AlmaLinux Foundation through a data sponsorship for their mirroring system: https://almalinux.org/blog/2024-08-07-mirrors-1-to-400/
But since privacy is a major concern for them, they should just use our IP-to-country database and host an API themselves on top of it: https://ipinfo.io/lite
We are happy to support and be part of any software that want to use our data.
I agree that it would be a more privacy-friendly solution for them to host their own API, but that got me thinking, wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads? That's also how the Server-Status Firefox extension (https://github.com/tdulcet/Server-Status) works (but it doesn't use IPinfo). Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
> wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads?
Of course, you can download our free IP database right now: IPinfo Lite
> Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
We are miles ahead of everyone in terms of accuracy. Currently, we have 1,100+ PoPs across the world running active measurements. While traditional IP geolocation services are no much more than ASN/ISP reported data aggregation and parsing services. Our priority above all is accuracy and at this moment we are likely the industry leader for that.
If you have the time, go through some of our posts in our community and you will be surprised how good our data is right now. I will share my recent favorite one:
https://community.ipinfo.io/t/the-north-korean-gamers-on-ste...
https://www.zdnet.com/article/3-ways-to-stop-android-apps-ru...
https://www.androidpolice.com/how-to-close-android-apps/
https://www.androidauthority.com/how-to-close-apps-on-androi...
An exception would be Windows applications that can be "run as a service". This is generally not default behaviour for user-installed Windows applications. It generally requires administrative privileges and manual configuration for each application
https://en.wikipedia.org/wiki/Windows_service
https://stackoverflow.com/questions/3582108/create-windows-s...
https://www.windowscentral.com/how-start-and-stop-services-w...
Unlike Windows, Android does not present an option to close an application while the application is in view. Android applications can be "swiped off" the screen, but they are not closed. By default, _all_ Android applications continue to run in the background. Closing an application in Android requires using a separate app. For example, opening the "Settings" app, then finding the app to be closed in a list of apps, then "stopping" the app by selecting "Force stop" as describeed in the articles above. If the Android user wants to close a number of applications running in the background simultaneously, she is out of luck. They can only be closed serially, one after the other. She must find each of them via the Settings app and Force stop each one, individually. This is extremely tedious and slow and, as one would expect, results in almost all Android users allowing applications to run in the background. The tedium mandated by this design could be purely coincidental.