Comment by Charon77
3 months ago
Remember how Android used to be an open source project and how we had Google backing AOSP? I think it's time we we maintain the latest fork and just use that instead.
3 months ago
Remember how Android used to be an open source project and how we had Google backing AOSP? I think it's time we we maintain the latest fork and just use that instead.
That only solves the OS side of things, but doesn't give you a good ecosystem. Unfortunately and increasingly bigger number of apps rely on Google services and attestations, meaning you need a Google approved software to run them.
I wonder if it'll promote having multiple devices, fragmenting into multiple ecosystems. One for the approved walled garden, another for uses that can exist without relying on those services (anything that doesn't need payments?).
Another approach I wonder about is single task specific hardware, like a GPS unit or media player, what tasks have developed over the past ~18 years within the mobile ecosystem and are mature and not rapidly evolving enough that they can be unbundled to their own devices, and desirable enough to stand alone that there's a market for it.
that's highly inconvenient, most people won't bother with that. The ~1% though will certainly do that, with black market apps and jailbroken OS will rise.
That's not the problem. It's the bootloader locked hardware and the TPM anti-"tampering" security verification that more and more apps require.
It's not just the OS makers. They're also responding to the demand of companies and governments to control their users through them. They will not say "no".
> It's not just the OS makers. They're also responding to the demand of companies and governments to control their users through them. They will not say "no".
I don't believe that entirely. For example, how much safer is a banking app protected by play protect, running on an OEM ROM with tonnes of OEM/Google/Meta malware, compared to the same running on Graphene, Lineage or Calyx? I think it's the other way around. Google or their associates convince either the banking firms, or more likely the security audit companies that the play protect (safetynet or whichever latest flavor) is an absolute necessity for security on android. In the latter case, those security firms will give the developers a checklist to follow, which will include an item on enabling that API. It's unlikely that so many banks will choose them on their own accord like that, even if a bunch of them insist on Google providing it. I have even seen banks disabling the API in their apps through updates. And they also don't have any problems with their web applications that don't have anything similar to remote attestation. Besides if you look closely, it's in Google's interest, not the bank's interest to enable these APIs. Such apps will only run on the OEM ROMs, making the open source and custom ROMs somewhat untenable.
I'm not sure banking firms need any convincing that attestation makes their systems more secure, as it is true. If the only way to interact with the app is via a human interface, that means you can't have scalable fraudulent traffic hitting your services. Without attestation, someone could MITM the app calls, and then automate it away.
Or when you do, you can then link it to specific group of people based on the identifiers you received from the attestation.
Is AOSP no longer a thing? I've been using GrapheneOS for a few years and admittedly lost track of AOSP, I just assumed it was still a thing despite Google generally wanting to control more and more.
Google now only drop through source code after a release, not during development. Also, much AOSP functionality has been moved to Googles Play Services which is closed source.