Graphene OS: a security-enhanced Android build

For those who don't want to root the phone, you can still avoid most of the ads by using a filtering DNS server with the Private DNS functionality on stock Android ROMs (or only at browser level if your favorite browser support DNS over HTTPS).

It comes with some minor usability issues with captive Wifi portals sometimes, but the trade-off of not having ads in app or while browsing is way worth it IMHO.

> For those of us who aren't ready to cut the umbilical cord to the mothership

You can use Google apps and apps depending on them on GrapheneOS via sandboxed Google Play. The vast majority of Android apps can be used. You don't need to stop using Google apps/services or other mainstream apps to use GrapheneOS. It's likely nearly all the apps you use or even all of them work on GrapheneOS. There's a per-app exploit protection compatibility mode toggle (and finer-grained toggles) to work around buggy apps with memory corruption bugs. We avoid turning on features breaking non-buggy apps by default and hardware memory tagging is temporarily opt-in for user installed apps not marked as compatible due to how many memory corruption bugs it finds.

A small number of apps are unavailable due to checking for a Google certified device/OS via the Play Integrity API. These are mostly banking apps, but most banking apps do work on GrapheneOS. There are tap-to-pay implementations which can be used on GrapheneOS in the UK and European Economic Area. Several banking apps recently explicitly added support for GrapheneOS via hardware-based attestation as an alternative to the Play Integrity API. We're pushing for more apps to do this and for regulation disallowing Google from providing an API to app developers for enforcing devices licensing Google Mobile Services. Play Integrity API often portrayed as a security feature but Google chooses not to enforce a security patch level. They're permitting devices with years of missing important privacy and security patches but not a much more private and secure OS. Only their strong integrity level has a patch level check, but the check is only done for recent Android versions and only requires they aren't more than 12 months behind on patches which serves no real purpose.

> you can also root/firewall on normal android

This is different from our Network permission which not only blocks direct access but also indirect access via APIs requiring Android's low-level INTERNET permission. Our Network permission also pretends the network is down through many of the APIs. For example, scheduled jobs set to depend on internet access won't run.

Graphene has a really great sandboxed google servicen implementation, so barring a handful of banking apps not working, switching to graphene is a very gentle cutting of the mothership. For me it was very subtle, with better battery life!

The Netguard app worked well for me for that on vanilla burners and such. No root, "VPN" that I had block pretty much everything but the browser and Signal.

Even without root, a VPN-style firewall will work against all non-system apps. The downside of this approach is that you can't combine one with another VPN app.

Root, while more efficient, isn't strictly necessary. AdAway (FOSS, F-Droid) can run without root using the stock Android VPN backend.

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.

Plenty of laptops exist you can get away with running fully open source and auditable firmware, and a few that are mostly open hardware too, by the MNT Reform team.

The Precursor is the only pocket computer platform that is maximally open hardware, software, and firmware but you revert back to the 90s in terms of power as a consequence with alpha quality software today. If Bunnie is successful with his IRIS approach and making custom home-user-inspectable ASICS then maybe a middle ground path can be forged in the next few years.

For now the only modern computing experience with fully open hardware and software I am aware of are the ppc64le based devices by Raptor Engineering, but at a very high cost due to low demand, with huge form factor and no power management. I still own one anyway because we have to start somewhere.

For those that want this story to get better, please buy and promote the products of the few people trying to break us out of dependence on proprietary platforms.

Anyways, we as informed consumers are hopefully all agreeing on striving for an open mobile OS and open hardware. For those of us, who consider themselves democratic, that is even an imperative.

Replicant was the last time we had fully open Android devices. We have regressed.

Not sure what the situation is with Librem, Pine and Joola/SailfishOS, maybe those qualify?

Yes, which is a huge problem. This is a big part of why Android phones suck so much ass - you're often stuck on old versions of android because the hardware vendors are too lazy to update their proprietary bullshit blobs that barely fucking work.

And now you're running a two year old phone and it's effectively obsolete.

If they would just upstream their firmware into the Linux kernel, you could upgrade these phones for years and years. Until the hardware is actually physically incapable of running the latest features.

Some vendors, like Google, promise to provide updates for a long time. But it's just that - a promise. There's no technical guarantee or mechanism for this, it's purely based on trust.

> As opposed to using what, hand gestures

As opposed to "being free in all senses of the word", which is what the comment was talking about.

People go through all sorts of weird mental gymnastics about this. The FSF at one point took the position that binary blobs were cool so long as they could not be upgraded, because then you could pretend they weren't software at all, but just part of the wiring. I've seen this odd line of thought attributed to RMS himself, but here's an FSF statement, from when he was running it: https://www.fsf.org/blogs/community/task2-openmoko

No production ready -mobile- hardware, I would agree.

The Precursor is promising, but software is not there yet.

I sit down at my desktop computer and send emails and type messages like this one. Then I get up from my desk and spend time with my family offline and present. It's pretty great.

FSF RYF certification is anti-freedom, anti-privacy and anti-security. Pretending hardware is open because there aren't closed source components which are / can be updated doesn't make sense. They certify closed source hardware with closed source firmware. In many cases, privacy and security has been crippled to obtain the certification by preventing important firmware upgrades. Not shipping firmware updates in the OS doesn't mean the firmware isn't there and doesn't make the hardware or firmware open source. GrapheneOS wants to have actual open source hardware and firmware, not what the FSF is peddling. We certainly don't want to block people getting important firmware upgrades needed to defend devices. FSF heavily misleads people about these topics for ideological reasons.

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.

Indeed, mainline linux distros aren't free software either

It's a standard Android feature with various apps available for different use cases. Some are for setting a specific location, others are for using an external device. It's a very generic feature. GrapheneOS plans to add a different feature called Location Scopes similar to our Contact Scopes and Storage Scopes features for setting a per-app location. Android's Mock Location is global.

Can you give me one that works on a stock Android? I used to use one but it no longer works on newer Androids.

Work profiles are inferior to separate user profiles, which are built-in to GrapheneOS.

Also "private space" is now available with Android 15 and can provide the same separation within a single user profile.

On the GrapheneOS forum you will see a lot of bad opinions about F-Droid, for example this:

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

Also check out Neo Store: ''An F-Droid client with modern UI and an arsenal of extra features.''

https://github.com/NeoApplications/Neo-Store

Just to add to that: Even some proprietary applications let you download their APK right from the website. WhatsApp is one such example (I don't recommend that you use it, Signal is much better, but if you require it, you don't have to use the Play Store).

I put them in the private space. Is there an advantage on putting them in the work profile?

It doesn't work for everything; one of the banks I'm forced to use checks for how it was installed, and Android for some incomprehensible reason is happy to report that to any application that asks (along with lots of other information like bootloader status and developer mode — you really have fewer rights to 'your' device than random applications).

After opening the application, it complains about being installed through an "insecure method", and bails. Reinstalling through Google Play magically fixes that.

These "security checks" are spreading like measles, so expect to see this sooner or later.

But than the apps you download (your banking app) require play services right?

So then what's the point of having a Play Store without Google Play services?

Banking apps are spyware, that's why they avoid open source OSes, not because they want to vendor-lock you. Smartphone data collected by a banking app is basically the most valuable in the world for advertisers, as they get the telemetry instantly crossed with a full(ish) picture of your spending habits and all the KYC identifiers too.

Depending on where you live, a burglary might be more common than a robbery. Why don't you just use the bank's website on your desktop computer (assuming you have a desktop computer)?

I'm concerned about losing phones too, so I don't bank on any phone.

Can you please clarify the Revolut part? Just to understand, you are saying that you are able to perform NFC payments via the Revolut app which you installed on your Graphene OS through the official Play Store? And you are based in Poland?

You shouldn't root Graphene, it breaks its security model and is certainly the reason why Revolut doesn't work on your phone. It works like a charm on mine.

Can you use mobilepay? (Or is that not a thing in Sweden?)

I can’t recall the switch, I believe it’s mem exploit protection. When disabled it typically fixes banking apps. You tried that?

GrapheneOS published a workaround for that in an update in January. https://grapheneos.org/releases#2025012600

https://grapheneos.social/@GrapheneOS/114772578787013282

Revolut works perfectly for me.

What kind of issues did you have? I think it does require google play services (which can be installed easily).

I have used GOS on a pixel 6 for the past two years with no issues. The phone finally died on me last weekend, so I'm in the market for a new pixel which will be getting GOS right away.

Revolut does work for me. They added support for GrapheneOS long time ago

I don't think the fork is very different right now, and I doubt inputting addresses works differently.

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

Awesome! Thanks for sharing this.

According to Terence Eden, Curve Pay allows NFC payments, at least in the UK

It will start out being their regular phones with security and updates improved to meet the requirements of GrapheneOS. When we demonstrate there's a huge demand for it after the products launch, we can have more influence. Our focus would be adding some security features not available on Pixels. The current aim is preserving the security we get from Pixels, but the future goals are more ambitious.

The Sony Xperia XZ1 Compact was the perfect size phone and I hate the world for not having successors of the same size.

Seconded! Need a smaller phone! and video out means i can make screen biggger if i want!

Do you guys all have that small pockets? I have a 6.7" Smartphone and never had an issue with its size

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

Pixels will be supported until end-of-life. Future Pixels will be supported if they continue meeting our requirements.

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

We expect 10th gen Pixels to meet our requirements and we should be able to add support for them. It's not going to happen in 12 to 48 hours from the official launch of the devices as we did for around the Pixel 6a and later. It will be more work. We've automated most of the device support for existing Pixels now and have removed nearly all of the Android 15 QPR2 device trees rather than manually updating them. We're continuing to automate more and will use that approach for supporting new Pixels.

The devices with an OEM partner are further in the future than the Pixel 10. We need Qualcomm's new SoC with hardware memory tagging support to launch because a flagship Snapdragon is the best fit other than the current lack of hardware memory tagging. Some things need to be addressed by the OEM including licensing extra things like Qualcomm and filling in some missing features. There needs to be a clear, workable plan for updates including Linux kernel LTS branches.

Pixel 10 will be supported by GrapheneOS provided it continues to meet our requirements - we'll know when it's out. It'll definitely take us longer than it has before.

A collaboration with an OEM doesn't mean we'll stop providing existing or future Pixels if they continue to meet our requirements.

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

Ahaha, don't get your hopes up, friend. The possibility of an adequate, degoogled Android with picky requirements as GOS on good, ultramobile hardware (matte DCI-P3 IPS, 3.5 mm audio, USB-C 3.2 or better, dedicated, ideally quick-access mSD card slot, IP68 rating, good cameras, EMR pen compatibility, changeable battery, non-plastic case) is virtually nil. That would essentially be a modern hybrid between a Samsung XCover Pro 6 and one of the older Samsung Note phones, e. g. the Note 9. Days long gone... :(

Agreed, pixel oled (and iphone oled) make my eyes blurry and achy and ia ssume its the pwm. ips laptop, other phones never have this effect

for me a non-OLED screen would be a non starter. I love reading text (white text with black background) and watching HDR videos on OLED screens

The comment above was describing in great detail how this is not the case and after some initial effort should prove no difference at all.

Generic power-user here: I am going to guess without the backing of Google going forcefully open-source, "niche" hardware such as Google's Tensor will lose their attractiveness.

However one must note also that for now not even Snapdragon fulfills GOS requirements. If/when that changes, Snapdragon devices may have more open-source community momentum than Google's Tensor. Plus all the economy of scale, etc..

In terms of security, Microtek is even more far behind Snapdragon.

Again, not an Android dev here, take the text above with a grain of salt, YMMV, etc..

GrapheneOS isn't a project that plans to be an aftermarket OS forever. In fact, we're currently working with an OEM to have their devices have official GrapheneOS support. This can mean devices being sold with GrapheneOS without someone even having to install it.

We're of the opinion that there's a growing portion of the population that is becoming more security and privacy conscious, and that's reflected in our userbase, which has been growing consistently over the last few years.

We're not saying we're going to have iPhone's marketshare, but we're constantly growing.

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

Yes, but at that point, the data is irreversibly rendered inaccessible. There are situations where the data itself is the most important factor, and where the owner of the device being hurt doesn't benefit the adversary now that the data is gone. Of course, as with everything, it depends on one's situation, but the duress PIN feature doesn't involve trickery. It's a way to reliably and quickly do a very specific thing.

These are ridiculous scenarios to try and optimize for. A smartphone feature isn't going to save someone from an abusive spouse or a serial killer, and if it does, it'll be an exceptional situation.

There was a youtuber who got kidnapped in Haiti a while back, and his kidnappers demanded to search the photo gallery on his phone for something. So what he did was delete the pictures, but not empty the trash, hoping they wouldn't know about that feature. They didnt, and he got away with it. Did Apple envision a kidnapping scenario when they were designing that feature? Probably not. Is there a design lesson that can be taken from that situation? Also probably not, because it just as easily could have gone the other way.

You can argue most bad people won't know about it - but I would say we can't really know.

I think the main problem is that people can be affected that aren't even using it, which is why it is such a big problem. You can't really hide it's GrapheneOS either, even just by virtue of the features available on the device, you'll be able to deduce what it is.

I understand the idea behind it but it simply isn't realistic to provide and can put people in danger - the very thing it's meant to prevent.

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

It's not about criminals. It's about the police, government spy agencies, and other knowledgeable threat actors.

We use Flarum for our forum, but Discourse similarly only allows one to view forum posts without JavaScript enabled.

We use Apple's location service, not beaconDB. We want to eventually make it so that it all happens offline, without any online service being used for it.

In newer Android versions, network location with microg requires an additional patch to work. Else you only get GPS.

See note at the bottom here: https://github.com/microg/GmsCore/wiki/Installation

We really appreciate the kind words!

Fairphone do not meet our requirements and haven't really been trending towards meeting them generation-by-generation. It doesn't seem to be something that interests them.

The unfortunate thing is that they make security promises which aren't upheld in practice (such as shipping security updates on time), so it doesn't inspire confidence as an OEM you could trust to properly support a device for multiple years.

We're hoping that there will be people who will enjoy a device from the OEM we're in talks with - we know that there are many people who for various reasons don't want a device from Google, so this will at least offer an option for people who want to use GrapheneOS on a non-Google device.

MTE is an Arm v9 feature subset of CHERI, https://news.ycombinator.com/item?id=30007474 | https://armor.ch/mte/hw

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.

> Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag?

It provides the ability to tag 16 byte granules of memory with 4-bit tags where only pointers with the correct tag can access the memory. This provides an approximation of memory safety very useful for security.

As an example of how it gets used, our implementation of the system allocators via hardened_malloc tags each allocation with a randomly generated tag excluding the adjacent random tag values and previous random tag value for the slot. It has the standard setup of a single statically reserved tag (zero) used for free memory but adds 3 more dynamic exclusions. This provides deterministic detection of small overflows, linear overflows, many forms of use-after-free and fallback to probabilistic detection of other spatial (bounds) or temporal (use-after-free) memory safety issues. We use a lightly modified variant of the standard MTE integration for PartitionAlloc in our Vanadium browser, but we plan to improve it to match hardened_malloc. We use the standard Linux kernel implementation for the internal Linux kernel allocators which needs a lot of improvement.

> why target requirements that even most desktop computers don't meet?

Desktop computers are far less secure than an iPhone or a Pixel with the stock OS. GrapheneOS exists to provide a higher level of privacy and security than those. GrapheneOS is primarily aimed at mobile devices which are almost entirely 64-bit ARM. Hardware memory tagging (MTE) is a standard ARMv8.5 / ARMv9 feature provided by every standard ARMv9 Cortex core. MTE is only missing with custom CPU cores or cache while cutting this corner.

Pixels are not the only devices providing MTE. Exynos and MediaTek have provided it and Snapdragon should be providing MTE starting at the end of this year. The only reason Snapdragon is late to the party is due to their custom cores/cache.

We're currently working with a major Android OEM towards multiple of their future devices meeting all of our requirements and providing official GrapheneOS support. They view all of our officially listed requirements as completely reasonable and a target they can meet for their next generation of devices.

The purpose of GrapheneOS is providing a high level of privacy and security, not making security less bad for devices people already have. Hardware and firmware security matters quite a lot and software security depends heavily on hardware-based security features including MTE. Nearly all GrapheneOS users buy a device to use GrapheneOS and that would still be the case if we supported several other devices. The vast majority of Android devices lack proper security patches for drivers/firmware, are missing important hardware-based security features and don't provide serious support for using another OS where the security features can be kept intact. Samsung's flagships are closest to meeting our requirements after Pixels but do not allow another OS to use verified boot, important secure element features and more. Samsung permanently cripples their devices if they're unlocked and voids the warranty, unlike Pixels.

The reason we're working with an Android OEM is because existing non-Pixel devices don't provide a base we can use to provide what GrapheneOS offers. It would be missing huge parts of the core features elsewhere and would be worse in significant ways than the stock OS. It would go against what we're trying to achieve to have people buy devices we can't properly secure. Long term support for drivers and firmware is also important because people use devices more than 3 years from launch in practice. Pixels get 7 years of proper support from launch, which is unique. A couple OEMs market their devices as having similarly long support but the updates are significantly delayed and far less complete.

We've had numerous opportunities to work with OEMs where they weren't able to provide our requirements. We simply aren't interested in having a far less secure device with GrapheneOS as the stock OS. We expect our requirements to be met, and we think the OEM we're currently working with is fully capable of providing what we need. It will hopefully be available in 2026 or 2027. The initial goal is not doing better than Pixels, just providing a competitive alternative for people who want to use GrapheneOS on another brand of device.

The other devices don't meet the criteria. Be happy that Pixels are supported, for Google seems to closing down Pixel OS too, making this whole effort rather difficult.

Because as mentioned, Fairphone has lackluster hardware security.

You can have the best alarm system in the word, if you leave the back door open and anyone can just walk in from the street.

According to the link you provided, it does seem to be ahead of stock Android (assuming AOSP) and LineageOS, disproving your point that it's falling behind.

The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.

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

But there is still no way to reset/spoof android device ids, and the apps can reliably identify the user after reinstalls.

Yes https://discuss.privacyguides.net/t/revolut-is-blocking-new-...