GrapheneOS doesn't implement or keep anti-user features. The way the linked repository is portrays things is not accurate. It gets the technical details wrong and also misrepresents the GrapheneOS decision making including portraying officially planned features as if they're things we disallowed because we didn't implement it yet.
You should use our official instructions for building and signing the OS. We provide official support for it including helping people with it in our development chat room available via Discord, Matrix or Telegram:
Building GrapheneOS is far easier than trying to modify the official releases. It's not hard to build and doesn't have a lot of dependencies on the host OS since it uses the standard AOSP build toolchain for reproducible builds. It takes around 40 minutes to do a full build of the OS portion of GrapheneOS on a recent 16 core AMD gaming CPU and half as many cores won't actually take twice as long since scaling isn't linear. It takes under a minute to do most incremental builds for testing changes after the initial build.
If you make your own builds, you don't have to modify anything to have root access via ADB. A userdebug build has root access in the Android Debug Bridge (ADB) shell via a su executable along with support for adb root to run ADB itself with root access so every command has it available including the shell, push and pull. You should enable ro.adb.secure=1 for a userdebug build if you intend to use it in production to enable USB-based ADB authentication like a regular user build. You should be aware userdebug reduces security through poking a lot of holes in SELinux policy in order to provide root access and the ability to disable dm-verity while unlocked.
Your own builds will not connect to releases.grapheneos.org for updates. If you want updates, you need to enable the Updater app by exporting OFFICIAL_BUILD=true after changing the URL to point at your own static web server. It's very easy to set up an update server and we publish official documentation and the sources for our services. We don't outsource our update systems to mirrors for privacy and security reasons. The app releases, OS releases and app repository metadata are signed with downgrade protection but that doesn't mean a mirror system is a good idea.
Here's a list of all default connections made by GrapheneOS:
You can choose to host only the network services and use our official app repository. If you rebuild one of the apps we update through there, just change the app id so it won't try to update it.
The services need to be updated before an OS update depending on changes to the APIs which are documented in the official release notes. For example, Broadcom GNSS moved to a new format for part of the PSDS data. It's all in 1 repository (grapheneos.network) if you don't host app and OS updates. You can host all this stuff on 1 server but we use separate ones for network services and updates since the load is so dramatically different.
The approach in the repository you're linked was always a very fragile and improper way of doing things. GrapheneOS is an open source project and you should modify the sources if you want to make changes.
GrapheneOS has officially planned support for toggling off secure activities disabling screenshots, toggling off apps detecting screenshots, built-in network-based location with multiple options including fully offline support via scraped data and Location Scopes for per-app location spoofing to go along with our Contact Scopes and Storage Scopes features. We don't understand why this repository is portraying these things as if people need to modify GrapheneOS to obtain them. If people helped us implemented the features in GrapheneOS, they would be available to everyone. Built-in network-based location is one of our top priorities and our implementation is nearly ready to ship in a production release. Location Scopes is a relatively high priority. The screenshot-related ones are low priorities but someone who considers it important can contribute and get it implemented soon.
The linked README has many inaccuracies about how things work and why they work the way they do. GrapheneOS has a built-in encrypted backup system which backs up data for every app since it uses the device-to-device backup mode. Play Store requires apps to use a modern API level for both updates and new apps along with unlisting apps not updating their API level for a few years. Therefore, the issue of certain apps not supporting backups due to opting out of cloud backups or excluding their files from cloud backups has been solved. allowBackup is not a thing anymore and neither are the traditional file exclusions. Apps can specifically exclude files from device-to-device backups for security or portability reasons, but few do, and it's almost always for a good reason. Apps can provide a backup service to backup and restore with a portable format. Files are often device or install specific. Logins also usually aren't meant to be cloned and can be made device-specific with the hardware keystore, as can other data. Signal encrypts their whole database with the hardware keystore so ignoring the backup exclusions won't achieve anything.
The hardware keystore works as a normal HSM does for good reason and it has attestation to prove keys are backed in a TEE or secure element along with verifying the OS. This gets into their mention of the legacy SafetyNet Attestation API and the current Play Integrity API. We had a feature filed about spoofing Play Integrity, but only spoofing the software device integrity level is possible and they require hardware attestation on devices properly supporting it. Pretending to be a Pixel with stock OS requires leaked keys. Pretending to be another device with the stock OS is easy for them to block via their extensive fingerprinting including GPU fingerprinting. Any attempt to do spoofing at scale can be blocked by them. It would be a black hole for development effort, and users would not have a reliable way to use apps banning using any aftermarket OS or non-Google-certified device.
Apps which want to forbid something like Mock Location such as Pokemon Go can and will use the Play Integrity API to require a Google-certified OS. Since GrapheneOS supports hardware attestation, they can check that it's unmodified GrapheneOS and permit it too, which we've convinced a few app developers to do:
Hiding that Mock Location is active simply means apps will not permit using GrapheneOS. It's pointless to trick apps about this when they won't permit using an OS tricking them. We haven't decided what to do for Location Scopes. Our approach will likely be making a new API so apps banning Mock Location will be compatible but apps which want to ban spoofing location don't have to ban GrapheneOS. That way, apps unaware of GrapheneOS will work with it if they don't ban it and apps aware of it don't have to ban it. What's a better option?
We're not doing anything anti-user. Preserving the security model in the regular production releases is not anti-user but rather pro-user. Most people aren't ever going to be using CLI commands while understanding and truly consenting to what they're doing by reading the documentation.
App-accessible root is not something we think is at all pro-user and the apps using it are taking a shortcut to implementing something without following the principle of least privilege, etc. By definition, it's not a secure way to implement functionality. It inherently gives root to a massive portion of the OS and can't truly be revoked. Users having root themselves via ADB is a different story but it doesn't mean it's a good idea to have that in regular production builds for everyone. It has a cost.
First off, thanks for all your work on graphene! I run cyber security for a company in the defense space, with data-sovereignty requirements, and you guys are the only serious project around. You should think about selling support contacts, I know a lot of BlackBerry refugees still looking for something serious. I bet you could sell support and a barebones MDM as subscription /very/ successfully.
(As an aside, I've been very happy to see you are still involved with the project!)
> GrapheneOS has a built-in encrypted backup system
Do you mean seed vault? It's really not satisfactory. For one, I should be able to encrypt my backups with any key of my choosing, on a hardware token if I so choose, not be forced into its silly codeword system or nothing at all. AES, gpg, and X.509 compatible support would get you all of the way there.
Even just letting backups be exported unencrypted, so I can easily and automatically use a trusted device to encrypt it the way all my other data is would make it so much more usable.
Frankly, the current implementation just reads as one of those ridiculous things trying to force the uneducated/uninterested to be secure, with no escape hatch for people who actually know what they are doing, nor for enterprises who need secure mobile devices, but also know an end-user will /never/ successfully take a backup on their own.
> First off, thanks for all your work on graphene! I run cyber security for a company in the defense space, with data-sovereignty requirements, and you guys are the only serious project around. You should think about selling support contacts, I know a lot of BlackBerry refugees still looking for something serious. I bet you could sell support and a barebones MDM as subscription /very/ successfully.
It's something we can consider in the future. We do plan to make our device management system with a unique approach not available elsewhere in the industry. We'll wait until we have it implemented to explain it.
We have funding to continue expanding the project and need to focus on that before trying to get funding in more ways than donations. We've been successfully expanding the development team. It's the non-development aspects which are barely in place.
Bear in mind our open source project has been around since 2014 but the non-profit organization was only formed in March 2023. There was a false start through forming a company in 2015 to support the project, then having it go off the rails and try to take over the open source project followed by years spent trying to destroy the project when that didn't work. It resulted in a lot of lost time, energy, money and opportunities. From a development perspective, GrapheneOS is a very mature project. From an organization perspective, we're still rebuilding from what happened in 2018. The focus is very much on development and building out the non-profit isn't easy for us.
> It's really not satisfactory.
We know it didn't turn out the way it was planned. Someone made the initial implementation for our use based on our design specifications and input. It was meant to become an official GrapheneOS project. We gave our design concepts to someone who began working on it, but the takeover attempt in 2018 lined up with this in a way that it got derailed. Today, this backup project is controlled by people directly involved in the takeover attempt and subsequent attacks on GrapheneOS. Believe me, we're not fans of the project and intend to either incrementally rewrite it or outright replace it.
The basic concept we created was an encrypted backup system able to support local backups, backups to an external drive, direct transfers from one device to another, arbitrary sync providers, etc. There was a whole vision for what it was meant to be but only certain aspects of it got implemented and mostly not in the way we intended at all. The fact that it exists acts as a barrier to making something better because we don't want to rip it out and start over with something not fully functional. It's easier to start a new project to add a missing feature than to figure out what to do about replacing an incomplete and low quality implementation of what we wanted from this. We need to figure out a whole migration plan away from it to something new where the old system doesn't go away until the new one at least does what it can do better.
> silly codeword system
It's a standard BIP39 seed phrase. It was meant to be a lot less limited than it is. There was a vision for what it should be which was partially communicated. The current team working on it doesn't understand the original vision for it and is not capable of creating something on the level we wanted to have.
Are you aware that the title of this submission is "The paper passport's days are numbered" ? Not "Why You Should Use GrapheneOS?" Way to hijack a discussion about what is fundamentally a human rights issue.
I responded to two posts directly about GrapheneOS. I tried to give helpful information on the correct way to do what they want to do and addressed the idea that we're doing anything anti-user. The linked content is misleading and it's only fair that we have a chance to give our perspective and explain our decision making. A lot of what was listed is stuff we plan to change but there have always been lots of higher priorities. The rest are security vs. incredibly niche features where we choose security but people can still have it the other way due to it being open source.
You should use our official instructions for building and signing the OS. We provide official support for it including helping people with it in our development chat room available via Discord, Matrix or Telegram:
* https://grapheneos.org/build * https://grapheneos.org/contact#community-chat
Building GrapheneOS is far easier than trying to modify the official releases. It's not hard to build and doesn't have a lot of dependencies on the host OS since it uses the standard AOSP build toolchain for reproducible builds. It takes around 40 minutes to do a full build of the OS portion of GrapheneOS on a recent 16 core AMD gaming CPU and half as many cores won't actually take twice as long since scaling isn't linear. It takes under a minute to do most incremental builds for testing changes after the initial build.
If you make your own builds, you don't have to modify anything to have root access via ADB. A userdebug build has root access in the Android Debug Bridge (ADB) shell via a su executable along with support for adb root to run ADB itself with root access so every command has it available including the shell, push and pull. You should enable ro.adb.secure=1 for a userdebug build if you intend to use it in production to enable USB-based ADB authentication like a regular user build. You should be aware userdebug reduces security through poking a lot of holes in SELinux policy in order to provide root access and the ability to disable dm-verity while unlocked.
Your own builds will not connect to releases.grapheneos.org for updates. If you want updates, you need to enable the Updater app by exporting OFFICIAL_BUILD=true after changing the URL to point at your own static web server. It's very easy to set up an update server and we publish official documentation and the sources for our services. We don't outsource our update systems to mirrors for privacy and security reasons. The app releases, OS releases and app repository metadata are signed with downgrade protection but that doesn't mean a mirror system is a good idea.
Here's a list of all default connections made by GrapheneOS:
https://grapheneos.org/faq#default-connections
Here's where you can get what you need to host all of this yourself, which is quite straightforward and easy:
* https://github.com/GrapheneOS/releases.grapheneos.org * https://github.com/GrapheneOS/apps.grapheneos.org * https://github.com/GrapheneOS/grapheneos.network
You can choose to host only the network services and use our official app repository. If you rebuild one of the apps we update through there, just change the app id so it won't try to update it.
The services need to be updated before an OS update depending on changes to the APIs which are documented in the official release notes. For example, Broadcom GNSS moved to a new format for part of the PSDS data. It's all in 1 repository (grapheneos.network) if you don't host app and OS updates. You can host all this stuff on 1 server but we use separate ones for network services and updates since the load is so dramatically different.
The approach in the repository you're linked was always a very fragile and improper way of doing things. GrapheneOS is an open source project and you should modify the sources if you want to make changes.
GrapheneOS has officially planned support for toggling off secure activities disabling screenshots, toggling off apps detecting screenshots, built-in network-based location with multiple options including fully offline support via scraped data and Location Scopes for per-app location spoofing to go along with our Contact Scopes and Storage Scopes features. We don't understand why this repository is portraying these things as if people need to modify GrapheneOS to obtain them. If people helped us implemented the features in GrapheneOS, they would be available to everyone. Built-in network-based location is one of our top priorities and our implementation is nearly ready to ship in a production release. Location Scopes is a relatively high priority. The screenshot-related ones are low priorities but someone who considers it important can contribute and get it implemented soon.
The linked README has many inaccuracies about how things work and why they work the way they do. GrapheneOS has a built-in encrypted backup system which backs up data for every app since it uses the device-to-device backup mode. Play Store requires apps to use a modern API level for both updates and new apps along with unlisting apps not updating their API level for a few years. Therefore, the issue of certain apps not supporting backups due to opting out of cloud backups or excluding their files from cloud backups has been solved. allowBackup is not a thing anymore and neither are the traditional file exclusions. Apps can specifically exclude files from device-to-device backups for security or portability reasons, but few do, and it's almost always for a good reason. Apps can provide a backup service to backup and restore with a portable format. Files are often device or install specific. Logins also usually aren't meant to be cloned and can be made device-specific with the hardware keystore, as can other data. Signal encrypts their whole database with the hardware keystore so ignoring the backup exclusions won't achieve anything.
The hardware keystore works as a normal HSM does for good reason and it has attestation to prove keys are backed in a TEE or secure element along with verifying the OS. This gets into their mention of the legacy SafetyNet Attestation API and the current Play Integrity API. We had a feature filed about spoofing Play Integrity, but only spoofing the software device integrity level is possible and they require hardware attestation on devices properly supporting it. Pretending to be a Pixel with stock OS requires leaked keys. Pretending to be another device with the stock OS is easy for them to block via their extensive fingerprinting including GPU fingerprinting. Any attempt to do spoofing at scale can be blocked by them. It would be a black hole for development effort, and users would not have a reliable way to use apps banning using any aftermarket OS or non-Google-certified device.
Apps which want to forbid something like Mock Location such as Pokemon Go can and will use the Play Integrity API to require a Google-certified OS. Since GrapheneOS supports hardware attestation, they can check that it's unmodified GrapheneOS and permit it too, which we've convinced a few app developers to do:
https://grapheneos.org/articles/attestation-compatibility-gu...
Hiding that Mock Location is active simply means apps will not permit using GrapheneOS. It's pointless to trick apps about this when they won't permit using an OS tricking them. We haven't decided what to do for Location Scopes. Our approach will likely be making a new API so apps banning Mock Location will be compatible but apps which want to ban spoofing location don't have to ban GrapheneOS. That way, apps unaware of GrapheneOS will work with it if they don't ban it and apps aware of it don't have to ban it. What's a better option?
We're not doing anything anti-user. Preserving the security model in the regular production releases is not anti-user but rather pro-user. Most people aren't ever going to be using CLI commands while understanding and truly consenting to what they're doing by reading the documentation.
App-accessible root is not something we think is at all pro-user and the apps using it are taking a shortcut to implementing something without following the principle of least privilege, etc. By definition, it's not a secure way to implement functionality. It inherently gives root to a massive portion of the OS and can't truly be revoked. Users having root themselves via ADB is a different story but it doesn't mean it's a good idea to have that in regular production builds for everyone. It has a cost.