I've got a Pixel 9a expected to arrive today, specifically for it to run GrapheneOS. One of my old phones was a Nexus 6P running CopperheadOS (prior to the dispute that spawned GrapheneOS), and it was great back then. Looking forward to how things have progressed in the years since.

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

"Great to have Google kicked off the phone"

Except the default browser is Chromium with some changes

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

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

It even offers a sandboxed Google Play Store

It tries to copy Google paternalism

It swaps a Google mothership for a Graphene mothership

What if the computer owner does not want a mothership

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

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

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

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

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

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

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

One does not even need Netguard to see this subversive activity

Try this at home

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

Put the phone on the same network as this computer

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

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

> So nice to shut off the network permission for any apps that only require an internet connection to serve ads.

For those of us who aren't ready to cut the umbilical cord to the mothership, you can also root/firewall on normal android to stop this. In fact I choose to not be able to use banking apps in order to cut out the crappy ads.

It's not all grim. GrapheneOS utilizes IOMMU to isolate the baseband and sandbox the wireless components. Even with binary blobs, the wireless radios cannot read encrypted traffic.

https://grapheneos.org/faq#baseband-isolation

Sure, it's not perfect, but it's still really, really good. Even with the binary blobs that are on it, Graphene phones have been impossible to unlock via commercial cracking tools since 2022.

https://osservatorionessuno.org/blog/2025/03/a-deep-dive-int...

Let's not allow the perfect to be the enemy of the good. GrapheneOS does what it can to isolate those things as much as possible. It even makes good use of hardware features such as the IOMMU. It's a huge improvement on the status quo, even though it's not going to pass FSF RYF certification.

Was there ever? And is the situation improving or worsening?

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

Laptops, desktops, smartphones or tablets are closed source hardware with closed source firmware in general. There are products marketed as if they're open source devices which are in fact closed source hardware with almost entirely closed source firmware. The software on top being open source is frequently misrepresented as the device itself being open source, which isn't the case. Not shipping important firmware updates in the OS provides assurance of insecurity while not changing the fact that the hardware and firmware is closed source. It has to do with a loophole defined in a certain ideology around software, not open hardware or privacy/security.

As opposed to using what, hand gestures? There is simply no production ready hardware with non-proprietary software at all.

This is also the case with mainline linux though. Good luck using Nvidia graphics with only FOSS components.

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

Mock Location is a standard Android feature available in GrapheneOS. Our upcoming Location Scopes feature is being added for per-app control rather than global.

It's fairly pointless for apps to check for Mock Location being active without also verifying the OS via the Play Integrity API or hardware attestation API. Most apps checking for it are using or in the process of adopting the Play Integrity API. Apps enforcing the Play Integrity API basic/strong integrity level won't work on GrapheneOS unless they explicitly allow it. A growing number of apps doing this are explicitly allowing GrapheneOS. It would be counterproductive if our Location Scopes API didn't provide a way for apps to check if since those apps simply wouldn't permit GrapheneOS. However, it doesn't need to be the existing Mock Location API. It can be our own API which would only be used by apps explicitly choosing to permit GrapheneOS. This would allow apps like Pokemon Go and Ingress to permit GrapheneOS even if they insist on not allowing directly spoofing location.

I believe this is in the works: https://bsky.app/profile/grapheneos.org/post/3lqbhoqwrjs2y

My understanding is that Mock Location on android is a developer setting that apps can easily check for, and as such, is basically useless (it will not fool any app that is asking for your location).

It's basically only useful for debugging.

Not by default, but there are several apps on F-Droid that do this

Obtanium[1], F-Droid[2], Aurora Store[3] and FFUpdater[4] are some options. Signal self updates from the APK download[6].

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

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

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

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

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

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

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

Aurora Store on F-Droid is a FOSS frontend for the Google Play Store that is a seamless drop-in. Requires no Play Services, nor an account.

F-Droid app store. https://f-droid.org

Someone's keeping a list of banking apps known to currently work with GrapheneOS: https://privsec.dev/posts/android/banking-applications-compa...

Check if yours is on the list.

I hate that many banking apps refuse to run on non-Google OSes. I can see that my banking app doesn't even work on GrapheneOS based on the link given in a sibling comment. It makes absolutely no sense from a security perspective since I am still able to log in using the browser, and the web app has the exact same UI and authorization flows as the actual app.

It all seems like a security theater with the consequence that, ooops, we just vendor locked in all our customers to run a less secure OS by a company whose business it is to collect personal data and show ads that people don't want to see.

I'm always afraid of my phone getting stolen or losing it somewhere so I have a completely separate iPhone, which runs my banking apps. I keep that phone at home.

It depends what banking apps you use. Some are available. From my observation major banks in Poland work just fine. You can pay via NFC using the mBank app if you need to. Revolut also works fine. gPay just doesn't work however therefore you cannot pay with this via NFC. I use my Garmin watch to pay for all things in physical stores anyway, so no need for NFC payments anyway.

In Sweden all the banking apps I've tried works, including BankID.

Have a second profile with fewer restrictions for those apps you think you need but don't want to compromise security for. My second profile has one app, which is my banking app with all the dependencies it rudely requires for functionality

I have a rooted Graphene on a Pixel 9, and the only bank which isn't working is Revolut.

As a single datapoint, revolut does not work unfortunately, so I moved back to the default pixel OS.

Arrest this individual

Does the fork solve the issue with inputting addresses? Organic Maps will happily route to the correct street, but falls over when entering a standard format address (i.e. XXX Streetname Ave)

I do not use Aegis anymore, I use KeePassDX instead. It works for TOTP just fine.

JuiceSSH is still under development?

>Magic Earth: another maps app

>Vivaldi: power-user's browser

Propietary. Get Fennec with FDroid with Ublock Origin and some addons.

CoMaps: another maps app

StreetComplete: help update CoMaps and OpenStreetMap

Catima: for loyalty cards

I prefer Tubular which is a NewPipe fork with not only an ad blocker, but also with SponsorBlock and ReturnYouTubeDislike.

> How do push notifications and similar things work on GraphenOS?

Some apps require Google's FCM for push notifications. You need to install Sandboxed Google Play services from the GrapheneOS App Store and grant them unrestricted battery access (so they can run in the background, which is required for maintaining a network connection to FCM and delivering notifications). https://grapheneos.org/faq#notifications

Other apps like Signal use their own background connections, for example WebSockets, to deliver push notifications, but keeping a connection open for each app consumes more battery life than just having one background network connection. Also, not every app supports this.

For Signal specifically, the GrapheneOS project recommends either using FCM via Sandboxed Google Play, or installing Molly (https://molly.im/), a fork of the Signal client for Android, which makes some changes to reduce battery consumption when using WebSocket-based notifications. It also allows you to use UnifiedPush (https://unifiedpush.org/) for notifications instead, but that requires an application called mollysocket (https://github.com/mollyim/mollysocket) running on a server.

Push notifications work on GrapheneOS whether apps do it themselves, use UnifiedPush with the user's choice of provider or use FCM. UnifiedPush and FCM are a more efficient design where apps share a push connection. Unfortunately, many apps only support FCM and some support their own push as a fallback, but few support UnifiedPush. FCM works very well via sandboxed Google Play, which is an approach where Google apps can be installed as regular sandboxed apps with zero special access or privileges. Nothing FCM does actually requires special privileges and our compatibility layer makes it work without it.

GrapheneOS does not include sandboxed Google Play but rather includes an open source compatibility layer providing support for installing Google Play as regular sandboxed apps. They can't do or access anything more than other apps including the Google Play code running inside apps using Google Play which is the reason for choosing this design. It simply uses the same app sandbox and permission model which are both greatly improved by GrapheneOS for supporting running the rest of Google Play not bundled with apps using it.

Worth noting apps don't need Google Play services to use Google services and many Google libraries like Ads and Analytics work without it. FCM requires Google Play services but many of their libraries do. There are Lite variants of Ads and Analytics for keeping apps smaller which lose the ability work without Google Play services. The general reason for the design is they don't want to have huge apps and want to be able to update the clients for their services without app developers doing it and shipping an app update. FCM is one of the special cases requiring the central design for efficiency. UnifiedPush is an alternative with choice of implementation / provider.

Everything works out of the box, and it doesn't use a third party layer like MicroG. The difference is that Google's apps/services are not given admin privileges like they usually are, so you can selectively enable or disable things.

For example, installing an app on Google Play works like F-Droid. Once the download finishes, you have to open the Play store app to trigger a system dialog to accept the installation. On other Android devices, GPlay can install apps without your approval.

Does the NextCloud app now sync contacts and calendar? Last time I tried, years ago, it did not. I use DAVx5 to sync my NextCloud contacts and calendar, via CardDav and CalDav.

Absolutely. You can basically get almost the same experience as you would on a stock OS device, but with much better privacy. On the stock OS, Google apps get privileged access, so they can still access photos and your camera and all that, but what people don't realize is that their privileged access also includes things like usage data, hardware identifiers, etc. Using Google apps on GrapheneOS makes a lot of sense.

The only problems you might run into would be some features might require privileged access, things like Now Playing. Makes sense because normal apps cannot have unrestricted access to the microphone like that. Google Wallet works, but you cannot make payments because the app refuses to work on alternate OSes.

Besides that kind of stuff, though, I've used all sorts of Google apps without issues.

Over the years, Big Tech has given me reasons to trust them less and less. So I encourage you to be a rebel: cut Google out and live outside the system.

> We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.

Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference https://news.ycombinator.com/item?id=44586723)

Quite a lot of detail on this comment, thanks for that!

But I'm still left a bit confused about the future devices GraphaneOS will support:

Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?

You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?

Thanks again!

As you're working with the OEM, I hope you'll consider a model which will come with either an IPS screen or is compatible with a 3rd party IPS replacement.

I bought a Pixel 9 Pro Xl specifically to use with GrapheneOS. Unfortunately, its OLED and my eyes were incompatible. The PWM on the screen was terrible and I had to return it after some headaches.

Of course, none of that was the fault of GrapheneOS. I absolutely loved using it and think your project is vital.

I suppose this means that supporting future Pixel devices will be more difficult? If someone has the ear of anyone at Google, especially someone who works with Android, please share this cause with them!

Is it now possible to build a custom release of graphene for any of my non-Pixel devices or will that, again, bring graphene ninjas to my abode?

I am so excited about the thought of a GrapheneOS native phone!

> If they are selling off their device business

Android and Chrome are potentially going to be split from Google:

https://www.nytimes.com/2024/11/20/technology/google-search-... (https://archive.ph/egRL4)

Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.

I hate to say this but I don't foresee Graphene being "mainstream". Most users will stick to the stock ROM. The most "mainstream" custom ROM Lineage is only installed on 0.04% of Android devices as of 2023 [1]. Even if Graphene appears in some mainstream news, I highly doubt any ordinary person can recognize it when they see one.

If the threat model is hiding from random people, I think a hidden profile works very well.

Now let's talk about motivated adversary as you put it. Hidden profile and wiping are not either-or, they can coexist. If one is really targeted by a motivated adversary, it should be apparent in most cases, and the targeted person can choose to enter the wiping PIN instead of the secondary profile PIN.

Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.

[1] https://9to5google.com/2023/11/20/lineageos-number-of-device...

Tbh I’d say 99% of the criminals won’t know about this.

Let’s say someone have you at gunpoint, you can just give your mains profile pass.

If they don’t even know there is a secret profile you’re good to go.

You’re right, they might assume you’re hiding, but I’d say 99% won’t know what’s even graphene and from those who know I’d say they might force you and you can have 3 sets of bank accounts:

Main profile: 100 Secondary: 1000 Terriary: $$$

Also if you hide all traces of grapheneos would be safer too. Nobody even knows is graphene, so they can’t even check what features you have. Again we are talking about 99% of the criminals, not the tech savvy 1%.

I’d prefer plausible deniability like Vera crypt than what we have now.

There are certain threat/risk models where having multiple profiles might be helpful (non-forensic examination by an offical at a securtiy screening kinda scenario). But you're right, it's nuanced, requires know-how by the user, and possibly a foot-gun for some caught unawares. NOT an easy problem to solve. Personally, as a user, I'd like the ability to be able to choose that option in the instances where I needed it, but it's likey a TON of work for a very small actual user community who needs it.

I think this feature nowadays would be mostly for the border control checks, especially in the US. Basically to avoid being sent back over a JD Vance meme found at a glance, as opposed to actually being held hostage.

I remember a conversation with a political activist refugee. They were in a group of people who got checked at the border, and were asked to unlock their laptops. The border security personnel then proceeded to do a short inspection of the visible systems. They all used Veracrypt's Hidden Operating System functionality, and while it would be trivially detectable, the border security did not, so they got through without problems. If they had refused to "unlock", or used a duress passphrase that wiped the system without presenting a dummy version, they would have been held, possibly for a very long time, and definitely not allowed to exit.

Moral of the story: Different contexts allow for different solutions. It is a sign of false privilege to make assumptions, and not let the user decide. An argument can be made in terms of priority of implementation, but not in terms of "pointlessness". The often used argument of "false security" can be addressed by warnings; yes, some people may not understand the implications, but you do not need to make their own (bad/good) choices for them; that's paternalism, not care.

In the real world, where thanks to my political work I am in contact with many people who had to endure real-world security checks, police raids, investigations, and so on, in all the cases no proper (imaginary) forensic analysis was performed. People make mistakes and remain uneducated -- on both sides. The "But NSA!" argument brought forward typically by white techbros kills a lot of useful technology before it even exists, which is unfortunate for those that would actually benefit from it, and when asked would tell you so. It's also not either/or in reality: In many situations, it will buy you time (while e.g. your lawyer may try to get you and your devices out of the situation), and even if they find out you were trying to fool them, they may give you another chance, and then you can still opt for the wipe code. It makes a huge psychological difference to have multiple options and feel in control.

They say a hidden profile is not secure enough so not worth implementing.

I rather have this hidden profile that would stop 99% of criminals than what they have now.

I think their approach to this project is to deliver real security at the cost of features.

This is a fully general argument against any single thing your life might depend on: seat belts, defibrillators, bulletproof vests, etc.

If the only thing protecting you from getting shot to death is a bulletproof vest, clearly a lot has already gone very wrong, and you're likely to die today anyway. But that kind of thinking is exactly what leads to a failure to defend in depth.

Security doesn't mean you have to go feed the cows and leave behind everything.

In fact, a core aspect of security is having access to a feature in the very first place.

A forum, being hosted on the web has absolutely no reason to stay away from the de facto scripting language of the platform. What would be your threat model for that forum? A zero day that would break the whole world?

It is possible to view the forum without JavaScript being enabled, but not sign in and post. We use Flarum for our forum, and that's a limitation of the platform.

We use Flarum as our forum software for https://discuss.grapheneos.org/. Flarum supports viewing all of the content without JavaScript via an HTML fallback mode using pagination. Flarum simply informs people they'll have a better experience with JavaScript enabled.

Join usenet: https://www.eternal-september.org

Subscribe to comp.mobile.android. Sadly there's no libre client yet, but Mozilla might release a Thunderbird version with NNTP support.

You can read it just fine with Javascript disabled, though.

It's Discourse.

>>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost

> Graphene's new network location feature

I believe it uses https://beacondb.net/, which is starting to have fairly decent coverage, at least in large parts of Europe. You can contribute to BeaconDB even if you have an ordinary Google phone by installing https://github.com/mjaakko/NeoStumbler.

I use LineageOS myself (because Graphene no longer supports my Pixel 5), and unfortunately it doesn't do network location out of the box. You can get network location on LineageOS by installing MicroG, but it's currently somewhat flaky.

Extremely happy GrapheneOS user here. Thank you so much for the work you and your colleagues do. Speaking for myself, the adoption of a mobile communication and computing choice that both put me in control of what information I interact with and respects my agency enough to present me with the hard choices about what I do and don't want for myself has been a life-altering upgrade in something midway between "peace of mind" and "outright mental health".

Much like you don't hear the sound of a busy city until you go somewhere truly quiet, you don't remember owning your own brain until you evict all of the entities who have been living rent free in it.

Keep doing the great work you're doing: it's making people's lives better in dramatically more significant ways than most software.

I can understand the GOS' rationale in choosing only the most secure phones. However, I'm more concerned about privacy, and not so much about security. It'd be great to have something like a "GOS-Lite" which accepts some security compromises in order to bring privacy to more people. (And yes, I understand that lower security means less privacy from targeted attacks but even GOS depends on OEM blobs, right?)

If it's a repairable phone like the Fairphone, that would be fantastic. Otherwise, I'm already very satisfied with what you offer. Thanks for you work.

I'm working my way down your requirements.

> Hardware memory tagging

I had to Google this. Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag? Or are you only interested in the memory safety benefits? Regardless, why target requirements that even most desktop computers don't meet?

I really hope it's the Nothing Phone you're talking to.

About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.

This is great to hear. I hope the ORM has a budget model graphene can run on.

that is great but i hope it is not a small run with a 200+ price as happens with the various linux phones.

4-5 versions of the same phone in the gigantic sea of possible devices

GrapheneOS community manager here.

I would recommend checking out https://eylenburg.github.io/android_comparison.htm for a third-party comparison of these projects. They're not really similar.

CalyxOS downgrades security compared to the Android Open Source Project, often falls significantly behind on standard Android privacy and security patches as is the case right now (they still haven't ported to Android 16 which is required to have the latest patches) and doesn't provide similar privacy or security features.

Features like Contact Scopes, Storage Scopes and our Sensors permission toggle are some of the privacy features includes in GrapheneOS.

Privacy necessitates security. The security provided by GrapheneOS is in order to be able to protect privacy.

GrapheneOS community manager here. Google did make it harder to support Pixels, but we're still doing it and plan to continue supporting new Pixels provided they keep meeting our requirements.

At the same time, we're in communication with an OEM to have some of their devices have official GrapheneOS support, so we're moving towards redundancy.

por que no los dos?

Not at all. They are one and the same. Both of those things will literally destroy the computer freedom we enjoy today.

GrapheneOS can attest to the device's security. The question is whether the app developers will trust such an attestation. Will they put money, time and effort into evaluating and trusting GrapheneOS? Of course not. They will just decide to trust nobody except Google and Apple.

This is the future. We'll be discriminated against. Can't even log into an account from an "unauthorized device". Their servers will just refuse to talk to our phones if they can't cryptographically verify that we have not "tampered with" them. We'll be refused service straight up unless our computers are straight up owned by corporations.

This so called "integrity checking" is meant to protect the corporations from us, not the other way around. It's so we can't do things like hack our way around their "policies".