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.
Those who control the public opinion know that there's some opposition who confuses the problems with the conflict. They laugh since no one who thinks legislation like in the link would be generally bad can do anything. The ignorant will vote what the Orwellianishly-named "smartphone" will command them.
In the next five years, it's likely the option to stab the kings will be for the first time removed, since robotic militias will mean no insurance CEO can simply be shot. This means there will be zero limits to what cruelty they'll do you, since no matter how torturous it gets you'll be unable to even violently resist this. You'll have no democratic mouth, but you must scream. Completes cyberpunkization well.
---
Aside: US drones + US satellites that enable global connectivity of drones was a rather obvious consequence of Starlink ~4 years ago. If they really want some person, they now can search most of Earth in few hours with the drones + computer vision, and soon with land robots, all connected through Starlink (starshield to use the euphemism). The irony is how this at the same time solves the connectivity problem.
In Europe traditional news sources there got economically slaughtered & replaced by few big online 1995-2005. This qas a consequence 1970s & 1980s academic networks working closely with US on web, and US then doing what it did with Google.
If you can influence what ends up in the social media feed of those deciding about university curriculums and/or most politicians, that's quite powerful also.
In Russia & China, there seems to be less hidden, less culture of valuing "free media."
---
That public opinion "matters" but gets shaped is very plausible if you consider that most of history it didn't matter unless the public got very angry.
Century of Self describes the process before Zuboff.
One might argue that control of public opinion was originally more psychoanalytic idea, and then became more Skinnerian with computers.
> US drones + US satellites that enable global connectivity of drones was a rather obvious consequence of Starlink ~4 years ago.
One would probaby be safe from the US in Serbia, Transnistria and other non-US friendly places for a while, given enough bribe money. The US won't sneak drones into sovereign airspace without another state's approval even if they're looking for high level targets such as Osama bin Laden, Al Baghdadi, Qassem Soleimani. We are not talking about failed states or states in civil war like Syria, Libya or atates under US assistance like Iraq here.
The only place where you'd stand a serious chance is Russia, if there's political backing. (see Snowden, Marsalek et al.)
One reason I dislike such digital ID schemes because I can't actually tell what information (or metadata) is being forked over. Even if it does purport to show me, I'm just supposed to trust what it says?
No thank you. A piece of paper provides a common format that's easy for both me and the official inspecting it to understand.
Like the information on my visa application, or the fingerprints collected at that time, or my travel history, hotel stays, and so on.
Data does not have your be "in the passport" to follow me around.
Honestly I don't see any other way. Else it becomes a paradise for forgery.
Mafias all around the world will buy expensively any valid or even used identity document just for this purpose, i.e. to study it and perfect their forgery skills.
The process you witnessed is a remnant of the past, a feature of the necessary transition period, and I hope it disappears soon, because that's a giant gaping security hole.
Thanks to all those biometric data, in case of a problem, the process will be much more reliable using the database than using old fashioned paper IDs.
Also, all these tests are very fast to perform (excepted maybe DNA tests), much quicker than the unreliable administrative cross-checks that were performed until now when there was an ID issue.
Note: USA "paper" passports have included an RFID chip since 2007.
I don't think the UK (Or US, other other European) government are too torn up about the possibility of another Windrush scandal.
But I generally agree with you. A physical passport offers a degree of psychological and real "security" that the promise of some cloud-hosted credential absolutely does not.
As a minor aside, I (US citizen) was once able to able to enter the US (at Toronto Pearson airport) despite having left my passport in some hotel. I just told the stern American guy "Yo soy American." Apparently they have ways of telling.
How offline is the current system today, where officers swipe/scan our paper passports into a machine?
This is the same thing I am against a cashless society where the society no longer accept physical cash. And in 2012, and later 2014 when Apple Pay was introduced all the way to 2017, 99% of HN were in support of getting rid of physical cash.
In times of disaster, the people welding paper along with the people who can trade on their street cred, familiar friends, family, will get stuff, do necessary business.
Everyone else will be essentially panhandling.
Mind you, not a damn thing wrong with panhandling. That is not a crime.
My point is to avoid having to do that where possible and practical.
my passport has been through a washing machine accidentally and i can still present it in the remotest of countries no matter the internet or whatever, and it works
in the US, yes they are switching to face recognition and often they barely even look at the passport anymore. I enjoy the convenience of that, but i don't wish to share this data with all the countries in the world, nor to be on the hook for having a connected device everywhere in the world for basic movements.
So having digital vs physical passports opens no new avenues of private data sharing with regimes you might not trust: they already have a right to demand any kind of data they want about you.
Canada, at least, already uses an ETA system called exactly that (or I guess TAE in French), so that probably had greater influence than the US ESTA.
It’s a part of a wider trend going forward. I will say the UK/EU systems are fairly unique in that they aren’t excluding each other. Canadians don’t need ESTAs nor do Americans need Canadian ETAs
Airport WiFi - people can easily run deauth with aircrack-ng. Email server might be down Phone out of battery Etc
It's digital in the sense that it's electronically stored against your passport number, and the UK Border Force can see it just by scanning your passport.
Then, the digital passport's ship has already sailed for better or for worse, and all these questions are solved in other ways.
> when the Home Office messes up and accidentally deletes your immigration status
You're toast either way, because it will be checked at the airport. You'll have to deal with the immigration officer and have them do something, because you won't go very far with just a paper that will be checked against the backend. In my experience it has already been the case for a while now.
You still better have the reference paper that will help identify your visa procedure, dates etc. But it's already just a key to the info in the DB.
> you will no longer be in possession of any records
Print out the papers and keep track of the important pieces. It's the same for everything else in your life, including tax documents, birth certificates etc.
Even in the olden days, the papers you had only had value against the agency's record that could prove their validity. If you had to prove residency in some specific period, having a stamp on your passport would mean very little if the agency denied having any records of it. So it's exactly the same weight as if you printed out a certificate while the DB blew out and no data about it are left.
PS: I think in previous time people were also so much more lenient. It wasn't much a question of physical papers or not, and more on how much few people cared if your info was valid or not. I had an error in my name in many official documents, and while people noticed it, a simple "they typed it wrong" explanation was enough in 99% situations.
The home office rather notoriously destroyed/never kept its own records of arrivals of commonwealth citizens, which was one of the steps leading to the Windrush scandal.
Many older records only exist in paper form, and often the receipts are good enough. This is especially true when you’re dealing with 3rd party governments. A foreign government is going to put a lot more stock (rightly or wrongly) on a birth certificate that is printed on fancy paper covered in security features than it is to a printout of an email.
Also yes fancy paper is more valued than junky ones when nothing else remains, but random printouts are also provided everyday, and they're fine with it. At the crux of it, the foreign gov usually doesn't actually care that much about your birth certificate: they want due diligence at most, even if they'll have a more strict public facing facade. It's cross referenced only when it really matters (e.g. you're trying to get citizenship or a background check for security clearance ?)
That's not true. For example, Jews (or people who wouldn't be always considered Jews, but those who would still fall under the Law of Return) have to produce some kind of document which states that their ancestor was Jewish. Often these documents were issued by authorities that no longer exist. And it was up to immigration authorities to decide whether they trust such a paper or not. Basically, anything coming from Western Ukraine prior to Soviet occupation would be issued by such authorities, same with Baltics.
Unrelated to above: a lot of databases are only required to store their records for so long. For instance, the transcripts from most colleges can be produced within 10 or so years after graduation. Then it's like they've never existed. So, if for whatever reason you need to show your grades later, you better have a paper version.
Just to give an example of a document that I know had been submitted in this situation. A graduation certificate from a Jewish girls gymnasium in Vilno. The city has changed name since then, there's no such street address, there aren't any girl schools, definitely not gymnasiums, let alone Jewish. The building that used to be the school was destroyed in WW2. So, there's nobody who can vouch for the document. Maaaybe you could somehow find an index of all such schools that exited in the year of graduation, but even this info might not be available.
During WW2 a lot of civil records have been lost, especially in smaller towns / villages. Sometimes it was deliberate, especially if it was a Jewish settlement. It was common for Jews in the military to try to erase any trace of their ancestry, as regardless of how poorly the Red Army PoWs were treated, Jews and Communists would've been executed immediately. So, destroying records indicating such connections and forging personal documents was a common case. Now that people try to recover any traces tying them to their ancestors, they often have very little to rely on. Like, receipts from donating to a synagogue, or permits to start a particular business (typically associated with being a Jew) etc.
* * *
Another funny memory I have in this respect: in the 90's I was queuing in a bakery in some central part of Lviv. A man behind me overhead me speaking Russian (which wasn't very common at the time, since Lviv citizens frowned upon it, and mostly spoke Ukrainian), and decided to ask me if I know where Adolf Hitler street was.
My jaw dropped. But, the man pulled out from a pocket a triangular letter (the kind soldiers used to send during the war) with the address specifying exactly that. Apparently, the carrier of the letter was looking for his long-lost friend whose last known address was in Lviv, on that unfortunately named street. And since Lviv was seen as being quite radical in their way to dedicate streets to questionable historical figures, the old man believed that they might just have such a street...
Anyways, some locals overheard our conversation, and soon we discovered that the street in question was indeed named after Hitler during the German occupation, after Soviet occupation was renamed the Lenin street, but historically was called Lychakivska (and that was its current name, restored in the recent years).
* * *
Another similar story involves my dad's friend who was born in the 30's when the Soviets and the Nazis had a love affair. So, this guy was named Adolf, yes you guessed it, after the Austrian painter. He was Jewish. So, after the love affair ended, he sought to change his name. But you cannot change the name on the birth certificate. Also, his school graduation papers etc. all had him as Adolf, and that's how his family called him. Sort of. (I knew him as "uncle Dolik".) Not surprisingly, there wasn't much of a record of him changing his name to Alexei :) and he'd routinely get in trouble with all kinds of authorities, police when checking his driver's license, paying electricity bills etc.
Similarly, in Western Ukraine, prior to Soviet occupation, it was customary to give two names to children. Eg. my grandmother was Daria Anna. But the Soviet system didn't acknowledge this, and only one name could go into the passport / city records. So, she became Daria. At first. Then Dariana. And after having all sorts of documents, she was in a very tough spot proving ownership of her apartment, because it wasn't possible to tell (from the authorities perspective) whether Daria Anna, Daria and Dariana were the same person. Add to this that in order to preserve some of the family property she and her remaining relatives tried to mud the waters around these documents. Eg. to avoid partitioning the apartment she'd claim to have a sister Anna, who lived at the same address...
I'm quite sure that this wasn't an isolated incident. There would've been a lot of attempts to manipulate the system by creating fake people, trying to wipe out one's own records etc. Paper documents help in detective work to untangle such manipulations. If there was ever a single central source of this information, such manipulations would've been a lot more successful.
It hurts me. Everything going so far backwards.
At least once a week I have to screenshot something on iOS and use the new Photo OCR feature to copy and paste it out of the image. I wish I was joking.
I feel strongly that any future digital travel credentials that are offered by governments should be able to operate entirely offline, and provide records that can be retained by the data subject. That means that revocation is harder, but IMO that’s a tradeoff that is worth making to avoid another Windrush scandal.
This has already become a pain when dealing with countries that don’t stamp passports, because when you need to apply for something that asks for your travel history over the past 10 years, you might not have any records anymore.