GrapheneOS is currently the blessed child. Like CyanogenMod previously. They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google.
Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
An old article [1] but:
> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
Your claims about this don't make sense. Google does not provide compatibility with GrapheneOS for Google Play services. They do not provide support for using it or fix the issues introduced in new releases.
GrapheneOS doesn't license Google Mobile Services (GMS), doesn't include it in the OS and doesn't have Google certification. It isn't permitted by the Google Play Integrity API device and strong integrity levels because it doesn't have a GMS license. Google doesn't offer any way for GrapheneOS to license it.
We're legally allowed to provide compatibility with Google Play via our sandboxed Google Play compatibility layer. Similar to APK mirror sites, we're also allowed to mirror the freely available APKs.
We've put enormous time into developing sandboxed Google Play compatibility layer and there's ongoing work to continue resolving edge cases we haven't covered. If Google wanted Google Play to be used outside of stock operating systems licensing it, they could make it work as a set of regular sandboxed apps without us needing a compatibility layer. Our baseline compatibility layer isn't doing anything they couldn't do themselves by making them apps handle being portable to operating systems not deeply integrating it into the OS with highly privileged access.
> 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.
Permit faking hardware attestation by providing a remote attestation provider device that runs stock Android and a corresponding app. When app on GrapheneOS asks to be attested, that request gets routed via the cloud to the stock Android remote device. People will have to buy 2 phones, one running GrapheneOS that they actually use, one that runs stock Android that they can lock up in a closet plugged into power.
giving the option to completely block attestation and DRM API would be a good start.
> hardware attestation, which is not fingerprinting
this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.
the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.
if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos. how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
> giving the option to completely block attestation and DRM API would be a good start.
Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.
GrapheneOS does provide a toggle to block apps using the Play Integrity API because we found a small subset of apps using it are not yet enforcing providing a result due to being in the process of phasing it in. This doesn't apply to DRM or direct use of hardware attestation. We have a planned feature for blocking access to DRM as an attack surface reduction feature since it can eliminate a little bit of OS attack surface and a significant part of the TrustZone attack surface. Hardware key attestation has almost no attack surface and doesn't provide any info not available other ways.
> this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.
That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue. That's why they made a point of how they separated the systems for it, but you don't have to trust that on GrapheneOS. If you use a VPN it's irrelevant.
> the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.
That's not an accurate description. It's also implemented via our server by default too. If you use a VPN that's not relevant.
The MediaDRM ID is also widely misunderstood since it is scoped per-app rather than being global. The best way to address it is our planned DRM toggle.
> if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos
We disabled DRM provisioning and usage by default in Vanadium years ago and have a publicly visible feature planned for providing a toggle for native apps being able to use it. We don't have unlimited resources to get everything we want quickly implemented.
> how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
You're making attestation and DRM key provisioning sound far worse than it is. It's not fingerprinting and it doesn't give them another way to track users in practice. If services want to share data with Google then they don't need any of this to do it and it doesn't inherently result in anything being shared with them that's in any way useful. We have a planned feature for providing a DRM toggle but it's nearly entirely wanted for security, not privacy, and there are bigger security features to implement. There are many planned privacy features which would make a major impact rather than near zero as this would.
Preventing fingerprinting by websites is a very hard problem especially considering things like using timing and performance measurements for it. That's going to be a priority for us. Doing it for native apps would require a massive amount of changes to get anywhere close to websites. We could add 100 features reducing fingerprinting for native apps without accomplishing anything significant. We're focused on privacy features with a larger impact.
> Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.
which is what the user would want or be fine with in this case... present the option.
> That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue.
you appear to not know how it works, which doesn't inspire confidence.
both remote attestation packets and DRM license request responses contain a unique hardware identifier that can be extracted with knowledge of the right secret information.
in the case of attestation, privacy CA and the verifier must collude to do this (technically, you need the ephemeral key provisioning packet + attestation packet + secrets). blind signatures were proposed to make this impossible and REJECTED. using a proxy/VPN does not prevent having your unique hardware identifier be attributed to the attestation in this scenario. also note how when you attest to google both the CA and verifier are one and the same...
with DRM I'm not even aware of any effort to not directly expose the KeyBox public key to a license server, and ANY app can make use of DRM API. you do need the license server's private key to extract the identifier however.
>> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
>So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
It's a nice effort, but without preinstalls you aren't going to capture the market except for the tiny percentage of enthusiasts which are maybe a fraction of a percent of the market.
Google needs to experience real competitive pressure, and you need preinstalls for that.
Same story for year of the Linux desktop. It's doomed to 5% or less of market share without preinstalls (which Valve & the various other PCs now releasing with SteamOS are changing)
But also, prohibiting OEMs from making or partnering with "non Google approved" OSes is ridiculous and I'm surprised that hasn't been challenged in court yet as an abuse of monopoly power.
GrapheneOS has an official partnership with Motorola Mobility which is improving their next generation devices to meet our requirements and helping us port GrapheneOS to those. GrapheneOS will be officially supported on those devices with Motorola Mobility providing us with the stripped down hardware support code we need to support their devices with proper firmware/driver/HAL updates.
A bunch of companies are already selling devices with GrapheneOS installed. Those companies can start buying the future Motorola devices supported by GrapheneOS and doing the same thing with those which they already do with Pixels. Motorola can also specifically sell devices to other companies to sell with GrapheneOS with official support from Motorola.
> prohibiting OEMs from making or partnering with "non Google approved" OSes
It has been challenged in court and ruled to be illegal in South Korea and elsewhere. Regardless, it's only an inconvenience and can be worked around. Even if Motorola can't sell devices with GrapheneOS in many countries themselves, those can still be sold by other companies and Motorola can sell devices to those companies at wholesale rates where they can match the price of the non-GrapheneOS devices. Other than Google, most OEMs aren't directly selling most of their devices anyway.
> What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
It's definitely planned for GrapheneOS to be sold preinstalled on devices, but it will also be possible to buy devices without it and install it yourself with our web installer. The details need to be worked out. The focus is currently meeting the requirements and porting GrapheneOS to the devices.
> They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google.
Very little in GrapheneOS has gone back upstream post-Copperhead.
> Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.
> Very little in GrapheneOS has gone back upstream post-Copperhead.
Most of what we've landed upstream has been post-Copperhead. AOSP made it increasingly difficult to contribute without being an Android partner and it's nearly impossible now. We've contributed elsewhere including to the Linux kernel and PowerDNS. We don't try to submit security improvements to the Linux kernel anymore based on direct experience of it not being worth the effort required but we still submit patches for bugs. We're not interested in arguing with upstream developers about whether security improvements are worthwhile so we won't contribute those changes to projects not enthusiastic about it. We've made recent contributions to various projects we use including PowerDNS because they don't make it too difficult to contribute.
> What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.
Google didn't invent MTE or memory tagging.
Pixel 8 launched in October 2023 as the first production device with MTE and GrapheneOS began using MTE in production later that month. Pixel OS still doesn't use MTE by default and only began offering a way to use it with Android 16 via Android Advanced Protection Mode (AAPM). AAPM only uses MTE for a few core processes and apps explicitly opting into it which are nearly non-existent. It doesn't use it for the kernel, most of the OS or almost any user installed apps.
GrapheneOS uses MTE for the kernel, all of the base OS processes including apps with a tiny list of minor exceptions to work around HAL issues and many users installed apps by default. It supports opting into using MTE for all user installed apps by default and then disabling it for the ones not compatible with it which are becoming less common in large part due to GrapheneOS users reporting issues to app developers.
> AOSP made it increasingly difficult to contribute without being an Android partner and it's nearly impossible now.
Yes, by "upstream", I mean "upstream Android".
> Google didn't invent MTE or memory tagging.
Sure, they didn't invent memory tagging (SPARC ADI was an implementation from a decade ago, and I'd bet IBM had an implementation of something similar in like the 70s, judging by the rest of ISA innovations in the last decade), but they definitely invented the instantiation of it in ARM. Pretty much everything aside from instruction encoding for MTE was specified in a doc sent by Google to ARM in response to ARM telling Google something along the lines of "the entirety of our efforts in the security space are going to be spent on something that you're not going to see any benefit from within the next decade: CHERI aka Morello aka Arran".
Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
An old article [1] but:
> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...