Graphene OS: a security-enhanced Android build (opens in new tab)

I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.

Except the default browser is Chromium with some changes

This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that

Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else

It even offers a sandboxed Google Play Store

It tries to copy Google paternalism

It swaps a Google mothership for a Graphene mothership

What if the computer owner does not want a mothership

Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory

Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access

If the concern is apps that only require internet connection for ads, Netguard solves that problem without root

Most apps but not all will try to connect to the internet at some point, even if you never use them

The user-hostile design of Android is that apps keep running in the background after they are "closed"

(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)

Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.

One does not even need Netguard to see this subversive activity

Try this at home

Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD

Put the phone on the same network as this computer

Set the phone's gateway address to the address of the computer

Run tcpdump on the computer and filter for the phone's IP address

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.

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...

I am alright with things that allow for improvement, at least in theory

Even more FOSS friendly graphics vendors like AMD and Intel rely on binary firmware.

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.

I recommend putting proprietary Play Store apps grabbed with Aurora Store in the work profile with Shelter[5].

[1] https://obtainium.imranr.dev/

[2] https://f-droid.org/

[3] https://f-droid.org/packages/com.aurora.store/

[4] https://f-droid.org/packages/de.marmaro.krt.ffupdater/

[5] https://f-droid.org/packages/net.typeblog.shelter/

[6] https://signal.org/android/apk/

Check if yours is on the list.

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.

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.

> 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?

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.

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.

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

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.

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.

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.

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...

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.

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.

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.

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.

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)

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!

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.

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.

This isn't really a practical way of doing it. Google Play and Google Play Services having privileged access is more than sufficient.

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.

They hear their favorite influencer spout something, and they parrot it everywhere. Google bad, hurr durr.

Linking is fine, as you did here: https://news.ycombinator.com/item?id=44686876.

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.

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.

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!

> 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.

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.

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.

I run a b2b tech company in Silicon Valley and have not carried a smartphone in 5 years or had an LTE subscription in 6. I have a family and hang out with friends, mostly tech workers, at least once a week. I am online when I am at my desk or one of my family PCs, otherwise I am offline. It has been a massive productivity boost, attention span boost, and social improvement in every way.

I don't miss hours of doom scrolling a day and missing out on being present with friends and family. Took a few weeks to rewire my dopamine engine so the FOMO went away.

Phones -are- optional and if you think otherwise you might be an addict.

> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?

It is better in one way: a reasonably stable person holds the keys to the kingdom. Personally I do not like having -any- central person controlling my devices, so I just opt out of Android entirely until that situation changes.

I am a supply chain security researcher and founded a Linux distro where no single computer or maintainer is trusted, so trust decentralization, freedom, and control in software are very important to me.

CalyxOS 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.

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.

We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue.

In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works?

If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources?

> Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.

You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible.

> Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.

Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design?

> If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.

The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it.

He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.

I 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?

https://github.com/GrapheneOS/os-issue-tracker/issues/1174

> Although it is conterintuitive to use a Google device to get away from Google

The purpose of GrapheneOS is privacy and security, not specifically avoiding Google, which is not what privacy is about overall. Many companies including Android OEMs have worse privacy practices.

> Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.

There are a lot of ongoing attacks on the GrapheneOS project and our team including through fabricated stories and spin. People should look into the actual verifiable facts and look at who is being targeted with harassment and bullying. We defend ourselves from this including debunking inaccurate claims about the project and our team.

Is the camera with GrapheneOS as good as the stock android one? I get to use my wife's iPhone camera sometimes and it frequently shocks me how good and responsive it is. But I'm coming from a OnePlus 8 Pro, which never had a great camera in the first place.

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.

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?

Regarding NFC payments, the apps themselves refuse to run on non-vanilla OSes due to spurious security concerns and Google's maneuvers behind the scenes, but there are reports that Curve Pay works, at least in the UK.

I'll give it an install tonight. I'm curious to play around with it anyway and if I make minimal use of it, it should be pretty secure by it's use case.

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.

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.

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.

> 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.

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".