Android Developer Verification: Threat masquerading as protection

> and they are legally allowed to fingerprint grapheneos and block Play functionality.

No, and you also don't understand how the Play Integrity API is implemented.

Google has a bunch of monopolies tied to Android. Antitrust laws put limits on what they're allowed to do which Google has been egregiously violating for many years.

Google isn't legally allowed to pull a bait and switch with Android by changing it away from an open platform and open source project. They used Android being both of those things to build and expand monopolies in a bunch of areas. The way Google exerts control over OEM partners with Google Mobile Services licensing has already been found to be illegal in multiple countries and they're in the process of losing more court cases over it. South Korea found their terms to be highly illegal and Samsung is already largely free from their restrictions.

Play Integrity API enforces the Google Mobile Services licensing model. The licensing model and terms are highly illegal in countries with decent antitrust law. It has already been found to be illegal by the courts in multiple countries. EU and US have particularly strong laws where they're egregiously violating and that's going to have consequences.

Play Integrity API is primarily based on hardware attestation, which is not fingerprinting. The strong integrity level fully requires hardware attestation and services using it are migrating to enforcing that. Device integrity level requires hardware attestation for devices known to have a working implementation which is a major loophole but it's gradually being closed. Play Integrity API also has many software checks.

Play Integrity API software checks require having an immense amount of privileged access which means it's not very compatible with sandboxed Google Play without an immense amount of work which would achieve nothing. Tricking all the software checks won't make it start permitting GrapheneOS. It's not feasible to pretend the device is one without hardware attestation while avoiding it being detected that it's being faked. None of this can be feasibly bypassed in the long term without it repeatedly breaking and becoming increasingly impractical to bypass. Many apps already require hardware attestation via the strong integrity level and eventually Google will close the loopholes for the device integrity level.

> maybe once that happens grapheneos will finally take anti-fingerprinting seriously

It isn't fingerprinting and no amount of anti-fingerprinting will bypass it. Hardware attestation exists and it provides the device model and OS. It's also easy for apps to detect those in many ways. Apps can just look at their own memory and see the OS libraries loaded into them. The only way to pretend to be the stock OS even without hardware attestation would be making essentially no changes to anything since apps can look at a lot of OS libraries, etc.

Running apps in VM wouldn't solve anything either and will only work for apps which don't try to detect being in a VM and don't use hardware attestation or the Play Integrity API. We'll still need to support running apps on bare metal once we have VM isolation features since one of the main things apps doing these anti-tampering and attestation checks is trying to block is being run in a virtual environment.

As a natively Russian speaking Jew born in Crimea I really don't need any lectures on democracy from someone who ran away to Europe at the height of it's American enforced century of stability. My childhood was listening to stories from my great grandmother (born in Moldova) losing her entire childhood and several family members to European savagery. European so called Democracy isn't even one lifetime old. It's hilarious that you think Europeans have any moral high ground here whatsoever. It took the US to save Ukraine from the Russians and while the entire EU was waffling and talking about "escalation" we were actually doing something about it.

> It doesn't solve the current issue

These operating systems aren't compatible with most of the apps and services people want to use. It's going to become much worse. The compatibility layers several provide have extremely poor compatibility combined with disabling the Android security model and app sandbox. Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more.

Aside from that, many people care about privacy and security. Each of those operating systems is far less private and drastically less secure than the Android Open Source Project. None has a truly complete and working app sandbox or permission model. None uses modern exploit protections. None has serious hardware-based encryption features needed to protect against data extraction. They're not serious alternatives to an iPhone from a privacy and security perspective as an AOSP-based OS on decent hardware can be.

> but in case we don't manage to push back on this

It's a warning that's being added to Google Mobile Services operating systems. It doesn't negatively impact other operating systems based on the Android Open Source Project.

> various actual linux OSes for mobile

Linux doesn't mean GNU/Linux or systemd/Linux. It doesn't at all imply using glibc, systemd, GNU coreutils, Bash, GNOME, etc. Distributions using different userspace components including several of the ones you've listed are still Linux Android-based operating systems including AOSP and GrapheneOS are Linux distributions. Alpine doesn't use glibc and SailfishOS has a lot of their own mix of open and closed source software. Using a typical desktop Linux userspace stack isn't what makes it Linux and there's also not a lot of consistency in what's used on desktops regardless. A Linux distribution not using musl, glibc, GNU coreutils, etc. is still Linux.

> There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.

AOSP-based mobile operating systems are Linux distributions.

You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands.

Installing your own build does wipe the device when you unlock the bootloader, yes, but updating it with a locked bootloader does not. It would be a one time transfer if you have official images already installed.

Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.

The randomness of an app is irrelevant and apps need to jump through significantly less loops to obtain root access without your input. And even if they didnt do that, and you permitted root instead, the app can lie about you revoking it later in either case.

This is blind ideology over safety and real ownership. Root is a hacky shortcut for proper functionality, and is not a prerequisite to ownership in the slightest.

> Usability-wise, they are no match for Android and iOS—or even versions of them from five years ago.

They're also no match for the privacy or security of iOS or AOSP. They're bringing the lack of privacy/security model and protections on desktop operating systems and hardware to mobile. It's a massive regression for privacy and security despite being marketed in the opposite way.