Android became a lost cause the second they introduced hardware remote attestation.
Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video games. Can't do pretty much anything.
That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.
Play Attestation is a Google hosted database of build keys/hashes for known Android builds. Android-side of this attestation is an API which calculates and returns those hashes to the app.
There's nothing preventing the app from verifying the build itself against its own database. So they can allowlist GrapheneOS builds if they want - but of course that means that all other ROMs are still banned.
All of this has already been explained to fsflover in detail numerous times, but for any onlookers here are some of the project's thoughts on the subject of hardware attestation:
On the subject of root, it completely breaks the security model of the OS, and for very valid reasons they have no interest in having official installations with widely varying security models.
They also have no opposition to people creating their own forks to do so, and they publish comprehensive build instructions:
https://grapheneos.org/build
Thanks for the first link. I think I agree with everything written there.
> On the subject of root, it completely breaks the security model of the OS
This is just the opinion of the GrapheneOS team. I've never seen any actual data supporting it. Also it contradicts to the security approach of Qubes OS, doesn't it?
> Thanks for the first link. I think I agree with everything written there.
You're welcome, happy to help.
> This is just the opinion of the GrapheneOS team.
I don't think it can be dismissed as mere opinion, but even if it were, that's their prerogative: it's their project. A lot of people seem to think they should take counsel from everyone with an opinion about their free OS, even if it fundamentally changes the basic nature of the project, wihle people who are free to fork it and do what they like with it.
If we're going to invoke the concept that FOSS fundamentally means it's somehow more secure because we are free to audit it (a premise I find faulty but not for any relevant purposes here), we should expand that view to include the concept that anyone who publishes their FOSS project is under no obligation to increase their workload and change the fundamental nature of their project to satisfy requests they don't view as being in harmony with the project.
Anyone who's capable of auditing FOSS code is a thousand times more capable than they need to be to follow instructions to build a rooted GrapheneOS installation, and some do.
> I've never seen any actual data supporting it.
What kind of data are you envisioning that would support it?
> Also it contradicts to the security approach of Qubes OS, doesn't it?
That's an interesting question, but I want to make sure I'm understanding it right. In what way would it contradict it? Is it a case of, Qubes OS gives you root access in dom0, TemplateVMs and AppVMs, by GrapheneOS's logic, doesn't that undermine its security?
"Intended use" (as understood by Google) for my smartphone is apparently providing them with data, consuming their advertisements and overpaying for apps that display ads and where you need in-app purchases to unlock basic functionality.
> not as a hack for escalating privileges
Hack for "escalating privileges" on my own device so I can do nefarious actions like uninstalling bloatware, denying apps internet access, recording calls (legally).. how could that be?
>like uninstalling bloatware, denying apps internet access
All of these can be done with a computer.
>recording calls (legally)..
A second phone does the same thing.
>Hack for "escalating privileges" on my own device so I can do nefarious actions
Whether it's a "hack" is orthogonal to whether you control the device or not. I don't think anyone disputes that you "own" your linux PC, but using the well known `docker run --privileged ...`[1] method to get root on your machine is still a hack.
Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? I see no persistence.
And if I'm forced to install some crappy app on-the-go, the solution you propose is to always carry a computer with me, right?
> A second phone does the same thing.
So does a Phonograph from 1877, right?
> Whether it's a "hack" is orthogonal to whether you control the device or not.
I didn't object to it being called a hack, I just pointed out how evil and malicious that privilege escalation on my own device is. Google must block it immediately, it endangers the mankind.
>Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied?
Just use firewall VPN apps + VPN lockdown mode (ie. "block connections without VPN").
>So does a Phonograph from 1877, right?
I think it's fair to factor in what feature was lost because wireless-adb-on-localhost was removed. If some critical accessibility feature was lost, that would be far more important than something that's merely a mild annoyance, like needing a second device to run `adb install`.
>I just pointed out how evil and malicious that privilege escalation on my own device is. Google must block it immediately, it endangers the mankind.
Right, but going back to the docker root analogy, would you think it's unreasonable if people threw a hissy fit of linux kernel/docker developers added some security feature that blocked it?
Actually for any VPN apps that support per-app split tunneling, excluding a given app while vpn lockdown is enabled causes the app to be blocked. So you can have both.
Now, I’m waiting for a workaround to enable ADB, so sideloading can be handled now, too.
Android is not more open that iOS for a very long time now. The trend will continue.
Again, this is not a technical problem (the mindset of Google), so technological solutions won’t help.