I suppose the real trouble comes from needing to install software from the Google Play store in order to travel. If you feel you need to do that you can create a new Google account just for that installation of the Google Play from the phone itself and then never give it any of your personal information such as a payment method. GrapheneOS claims to do a pretty good job of sandboxing Google Play components.
Regardless I agree with others here who think it should always be possible to travel without any electronics on your person.
And like Linux on the desktop: it offers a better experience for everyone who either has the knowledge to step off the beaten path, or has someone who supports them. But that is just a few percent of people. The rest gets what market forces dictate.
https://github.com/chriswoope/resign-android-image?tab=readm...
I just wish there were a supported and easier way of achieving this. Would love any suggestions.
GrapheneOS is heavily focused on privacy and security. That means we're not going to add massive attack surface or poke huge holes in the security model for very niche things that are not going to benefit the vast majority of users. We provide official support for userdebug builds with ADB root access for people building the OS. Official support includes helping people with their builds in our development room, with the hope that people end up contributing back. People making userdebug builds for production usage should enable ro.adb.secure=1 unlike a regular development build. They should be aware of the security downsides and it's their responsibility to secure the computer(s) they're using for builds, signing and ADB access. ADB access can also be used on the device itself via network ADB which is non-persistent for security reasons.
GrapheneOS is an open source project. Modifying the official binary releases is not the intended way of making changes to GrapheneOS. People are intended to modify the sources and build it themselves. The whole process is only a few commands and can be trivially scripted if people only want production builds signed with their keys.
GrapheneOS even has fully reproducible builds for the OS and we have a community member that's reproducing each OS release successfully. There's only one known issue specific to 8th gen Pixels which has been worked around by them doing the 8th gen Pixel Linux kernel build from a specific path. It should be resolved already by Android 15 QPR2 that's currently in Beta due to it moving to the 6.1 kernel used for 9th gen Pixels for 6th/7th/8th gen Pixels too.
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.
(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.
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.
The 2 sentences making up that article don't really live up to that level of useful detail.
However, you already have to buy a passport (often for a lot of money) in most countries, so pragmatically, I don’t know that it’s a hugely different thing to ask. However, there’s a big difference for children, the elderly, and people with disabilities.
Immigration tends to stretch human rights though. It costs >10k gbp in visa fees for a British citizen to return to the UK with a non-UK spouse from arrival to settlement. You also need to be earning a fair bit of money, and not have the British partner as a stay at home spouse. I would say that frustrates article 8 ECHR, but the government disagrees.
There are countless examples of similar issues re international travel and immigration. Smartphone ownership is simply one of many.
A smartphone will not satisfy any of these properties.
Ownership of a device simply is not a guarantee you can rest on - even before you get to those who may not be able to use them.
Governments need to make sure that people can access the services that they’re entitled to through a wide variety of channels, including physically visiting an office if necessary.
Though I will say, at a practical level, you will find that it’s increasingly difficult for people with criminal records to travel internationally (due to entry requirements).
"Eligible" means you're able to be elected, but you must still be elected. Different from a passport, you may be eligible to a visa, and at some point an officer is likely going to interview you and decide whether to give you one.
People are entitled to a passport but only eligible to a visa. You can assert what you're entitled to, but not what you're eligible to.
> entitlement implies to me that the person has invested some time and resources in asserting their right
That's only when your title was earned, which not all are; some are born into them.
> I believe eligible is defined as meeting some criteria for, not necessarily being chosen though that could be a criteria.
The confusion may have started when decisions became more automated into "criteria" to be checked for by bureaucrats that no longer have the deciding power they once had (and later further automated by software), but "chosen" is in the latin root of the word. For example, "chosen" in Spanish is "elegido", "choosable" would be "elegible". "Eligible" = "electable" = "choosable". They're all basically synonyms.
Something else about what you said here, for titles that are earned (e.g. naturalized citizens), you don't invest time and resources to assert your right. You invest time and resources to earn the title. When you've earned the title, you've earned the rights that come with it. Having then those rights, you can then assert them. You don't need to expend anything to assert. You just claim them, since they're already your own. For example, if someone says you need to expend time and resources to assert your right to vote when you're already a citizen, that's wrong. Having expended time and resources to become a citizen (or having been born a citizen), it's already your right to vote. You're entitled to a vote.
From the government, paying what is more an administration fee than the actual cost of the good, yes.
This is about principles, not economics.
I won’t go into describing all the massive, gross, and blatant human rights violations that are actively going on right now all across the globe, because no particular instance is relevant to the fact that it’s unfolding, unraveling all across the western world in particular. And Mark my words, “human rights” will be a nullified concept when the western world has crumbled and gas succumbed to its infiltration and infection.