Its a version of android OS that can be installed on Google Pixel phones. Its a relatively easy switch if you’re technically inclined, but the device needs to be carrier unlocked.
No. As long as the base remains opensource (AOSP), they can remove the bad parts. Graphene has made numerous contributions to AOSP, I’m confident they can manage that. And if the user base growths, I hope their fundings will follow.
It would be a good thing for the world if AOSP was forked with big resources behind an open project with an open governance. But that needs lot of resources.
Neither is true, that’s not how forking works. But there is some truth to it in that it can start to become significantly more difficult to keep in sync as time goes on, depending on how obnoxious the security becomes and how many places they have to remove it.
Consider the trivially naive case where Google implements this feature in a single function: “function app_is_signed() -> bool” then the fork just adds “return true;” to the beginning of that function, and happily merges every other update Google makes from then on with zero issues. Even if the code for “app_is_signed” itself changes, nobody cares, because the first thing it does is return true and everything else Google ever tells it to check or do is ignored, the function can still be used everywhere throughout the code, it just no longer actually checks anything in Graphene, whereas it does check things in Google’s Android.
Of course the reality is much more complicated than that, but the principle is the same. It’s only a question of how obnoxious and difficult Google chooses to be about it. They could move the function around every update, or use many different functions, make a whole system out of it, make it do crazy cryptographic validations and checksums in various different places of the code, have watchdog tasks that are checking that the validation code is getting used. They could be really, really obnoxious about it, if they want to be, and they have more resources than the Graphene OS developers probably do to undo and keep undoing all these obstacles, so if they really want to devote that much time and energy to making Graphene’s position untenable, they can. But they could also be doing that now, and they’re not. Crackers have been fighting these sort of battles against copy-protected software for ages, it’s the same principles, and much of the same economic choices go into it. How much does Google want Graphene OS to go away? How much is it worth to them? It has to have a dollar value to them, and that dollar value might be significantly higher than they’re willing to bother with.
Worst case scenario where Google makes it extremely difficult going forward, what is the hard part about just never rebasing onto future work from Google?
From what I’ve seen there hasn’t been significant core work on Android for a long time. It’s been mostly changing from rounded corners to square corners to rounded corners, or shoving AI into every nook and cranny.
I’d think a small dev team like Graphene could maintain their AOSP fork moving forward.
I absolutely agree they can maintain an AOSP fork going forward, and I think that’s completely realistic and I would be surprised if that is not the case.
But I was answering OP from a strictly technical perspective about the potential difficulties they could, theoretically face while doing that. Since you asked what is the hard part, I’ll answer along those lines (again, with the caveat that I don’t think these are going to pose realistic obstacles for the GrapheneOS team in the near term) My point is not to say it’s impossible but I think it’s important for people to be aware that this approach comes with risks, and those risks will grow over time especially when you’re up against a non-cooperative upstream that is one of the largest and richest tech companies in the world.
For one thing you’re never going to support any new phones without either pulling driver support from AOSP or reverse-engineering the hardware and drivers yourselves, or accepting that some parts will just… not work. So you get stuck on older and less capable hardware. Maybe you don’t care about that too much, and that works fine for awhile, but eventually the cracks start to show. Now you have to either start figuring out how to get into the newer hardware, or you have to start getting custom newer hardware of your own, which is $$$.
Using closed hardware this way as leverage is a pretty common way of getting in the way of open source development, and Android hardware is very closed. Similar tactics are already even being used against x86 PCs now with things like TPM and Secure Boot. It doesn’t completely brick your system on day one of course, but the erosion of support begins when they start writing software that intentionally relies on these features to say “oh, sorry, this software you want to use? it won’t actually work on the open source OS/open source client because they don’t have access to this hardware… what a shame.” One or two pieces of software, no big deal. But they won’t stop there, eventually it’ll be like half the software, then over time it’ll become 90% of the software, you won’t be able to find alternatives. They can often afford to be more patient and relentless about this shit than we are. The battle will continue, and there’s no sure path to victory. Forking is one tool we have, and that’s great, but we also have to remember that it’s not a flawless, unstoppable long-term solution that we can play as a trump card whenever corporate interests do something bad. They don’t just give up. They have other means of getting their way.
It’s Android with all of the Google removed where possible and sandboxed where not. You can choose to install the Google Play services and use it like any other Android phone or use it without any Google software.
Some things won’t work, namely things like some banking applications and NFC payments, because they require on hardware attestation that Google will not allow Graphene to pass. Essentially everything that isn’t banking/payment related works exactly like any other Android phone.
It is just a secure phone (though you can still install Facebook on it if you want) that is designed around mitigating attacks that could violate your privacy and security.
Very easy to install, you just buy a Pixel directly from Google (don’t buy from the carriers, they’ll be locked). Enable OEM Unlocking in the Developer menu and then plug it into USB and you can install it directly from the Graphene site via WebUSB. It takes about 5-10 minutes, then your phone will reboot (It’ll give you a scary looking screen about not running a Google OS that you’ll see every time it reboots but it’s just informational, it doesn’t affect anything and the system will boot into GrapheneOS in a second or two).
The more complete instructions and WebUSB install process:
Why do banks need a hardware attestation, out of curiosity? I’d assume that banking apps are just clients so all that matters is if they have creds or not.
The banks don’t want their payment systems being accessed by devices that are compromised by malicious actors.
The attestation chain allows for Google to tell the apps ‘Yep, this system is running a known safe image that has been crytographically verified using the secure hardware on the device’. The apps will only allow their payment systems to be accessed (like, to send an NFC payment) if this check can verify that.
They don’t NEED it for NFC payments to work, this is a way of limiting attack vectors on their payment infrastructure (or, cynically, a way for Google to ensure that no competing OS can exist because people would rather give Google all of their privacy so they can pull a phone out of their pocket rather than a credit card.
Could you go over what Graphene is for phones? Is it easy to switch to an alternative to android?
Its a version of android OS that can be installed on Google Pixel phones. Its a relatively easy switch if you’re technically inclined, but the device needs to be carrier unlocked.
If it’s just a fork of Android, doesn’t that mean 194 days from now they either need to branch off entirely and write their own code from here on out…
Or…
Never advance the base code?
No. As long as the base remains opensource (AOSP), they can remove the bad parts. Graphene has made numerous contributions to AOSP, I’m confident they can manage that. And if the user base growths, I hope their fundings will follow.
It would be a good thing for the world if AOSP was forked with big resources behind an open project with an open governance. But that needs lot of resources.
Neither is true, that’s not how forking works. But there is some truth to it in that it can start to become significantly more difficult to keep in sync as time goes on, depending on how obnoxious the security becomes and how many places they have to remove it.
Consider the trivially naive case where Google implements this feature in a single function: “function app_is_signed() -> bool” then the fork just adds “return true;” to the beginning of that function, and happily merges every other update Google makes from then on with zero issues. Even if the code for “app_is_signed” itself changes, nobody cares, because the first thing it does is return true and everything else Google ever tells it to check or do is ignored, the function can still be used everywhere throughout the code, it just no longer actually checks anything in Graphene, whereas it does check things in Google’s Android.
Of course the reality is much more complicated than that, but the principle is the same. It’s only a question of how obnoxious and difficult Google chooses to be about it. They could move the function around every update, or use many different functions, make a whole system out of it, make it do crazy cryptographic validations and checksums in various different places of the code, have watchdog tasks that are checking that the validation code is getting used. They could be really, really obnoxious about it, if they want to be, and they have more resources than the Graphene OS developers probably do to undo and keep undoing all these obstacles, so if they really want to devote that much time and energy to making Graphene’s position untenable, they can. But they could also be doing that now, and they’re not. Crackers have been fighting these sort of battles against copy-protected software for ages, it’s the same principles, and much of the same economic choices go into it. How much does Google want Graphene OS to go away? How much is it worth to them? It has to have a dollar value to them, and that dollar value might be significantly higher than they’re willing to bother with.
Worst case scenario where Google makes it extremely difficult going forward, what is the hard part about just never rebasing onto future work from Google?
From what I’ve seen there hasn’t been significant core work on Android for a long time. It’s been mostly changing from rounded corners to square corners to rounded corners, or shoving AI into every nook and cranny.
I’d think a small dev team like Graphene could maintain their AOSP fork moving forward.
I absolutely agree they can maintain an AOSP fork going forward, and I think that’s completely realistic and I would be surprised if that is not the case.
But I was answering OP from a strictly technical perspective about the potential difficulties they could, theoretically face while doing that. Since you asked what is the hard part, I’ll answer along those lines (again, with the caveat that I don’t think these are going to pose realistic obstacles for the GrapheneOS team in the near term) My point is not to say it’s impossible but I think it’s important for people to be aware that this approach comes with risks, and those risks will grow over time especially when you’re up against a non-cooperative upstream that is one of the largest and richest tech companies in the world.
For one thing you’re never going to support any new phones without either pulling driver support from AOSP or reverse-engineering the hardware and drivers yourselves, or accepting that some parts will just… not work. So you get stuck on older and less capable hardware. Maybe you don’t care about that too much, and that works fine for awhile, but eventually the cracks start to show. Now you have to either start figuring out how to get into the newer hardware, or you have to start getting custom newer hardware of your own, which is $$$.
Using closed hardware this way as leverage is a pretty common way of getting in the way of open source development, and Android hardware is very closed. Similar tactics are already even being used against x86 PCs now with things like TPM and Secure Boot. It doesn’t completely brick your system on day one of course, but the erosion of support begins when they start writing software that intentionally relies on these features to say “oh, sorry, this software you want to use? it won’t actually work on the open source OS/open source client because they don’t have access to this hardware… what a shame.” One or two pieces of software, no big deal. But they won’t stop there, eventually it’ll be like half the software, then over time it’ll become 90% of the software, you won’t be able to find alternatives. They can often afford to be more patient and relentless about this shit than we are. The battle will continue, and there’s no sure path to victory. Forking is one tool we have, and that’s great, but we also have to remember that it’s not a flawless, unstoppable long-term solution that we can play as a trump card whenever corporate interests do something bad. They don’t just give up. They have other means of getting their way.
I’ll switch in a heartbeat if they support a nonGoogle phone
They’re working on it. Unfortunately most phones have poor security hardware, which is why its limited to Pixels at the moment.
It’s Android with all of the Google removed where possible and sandboxed where not. You can choose to install the Google Play services and use it like any other Android phone or use it without any Google software.
Some things won’t work, namely things like some banking applications and NFC payments, because they require on hardware attestation that Google will not allow Graphene to pass. Essentially everything that isn’t banking/payment related works exactly like any other Android phone.
It is just a secure phone (though you can still install Facebook on it if you want) that is designed around mitigating attacks that could violate your privacy and security.
Very easy to install, you just buy a Pixel directly from Google (don’t buy from the carriers, they’ll be locked). Enable OEM Unlocking in the Developer menu and then plug it into USB and you can install it directly from the Graphene site via WebUSB. It takes about 5-10 minutes, then your phone will reboot (It’ll give you a scary looking screen about not running a Google OS that you’ll see every time it reboots but it’s just informational, it doesn’t affect anything and the system will boot into GrapheneOS in a second or two).
The more complete instructions and WebUSB install process:
https://grapheneos.org/install/
What really bugs me about it: The first step from “how to ungoogle your phone” is “go, give money to Google” by buying their hardware.
Why do banks need a hardware attestation, out of curiosity? I’d assume that banking apps are just clients so all that matters is if they have creds or not.
The banks don’t want their payment systems being accessed by devices that are compromised by malicious actors.
The attestation chain allows for Google to tell the apps ‘Yep, this system is running a known safe image that has been crytographically verified using the secure hardware on the device’. The apps will only allow their payment systems to be accessed (like, to send an NFC payment) if this check can verify that.
If you want technical details: https://developers.home.google.com/matter/primer/attestation
They don’t NEED it for NFC payments to work, this is a way of limiting attack vectors on their payment infrastructure (or, cynically, a way for Google to ensure that no competing OS can exist because people would rather give Google all of their privacy so they can pull a phone out of their pocket rather than a credit card.