I think I found it https://discuss.grapheneos.org/d/12019-passkeys-as-mfa-on-grapheneos-a-guide
It might also be this one, I don't remember https://discuss.grapheneos.org/d/8184-graphene-os-3rd-party-passkey-support-on-android-14
Just about all of your identifying data is stripped out by the framework before interacting with Google at all
For all of them, we strip device identifier (MAC addresses, IMEI, etc)
This is literally nothing special, as all user-installed apps are denied access to identifiers like the IMEI and MAC address since Android 10. Since GrapheneOS isolates Play services in the Android application sandbox, they don't have access to any of these identifiers either.
I’m not too worried about memory exploits as I don’t really install apps
That's not how memory corruption exploits work. These can occur anywhere in the system, and just need to be triggered by an attacker. This doesn't require you to install an app, receiving a rogue message might for example be enough to exploit a memory vulnerability in the SMS app. Visiting a rogue website, which loads malicious JavaScript can be enough to trigger a memory corruption vulnerability in the Chromium WebView. That's why GrapheneOS doesn't just use hardened_malloc, but it also disables the JavaScript JIT compiler in Vanadium by default, and offers a toggle in the settings to disallow JavaScript JIT compilation in all apps making use of the system WebView component.
but why run it at all?
Because it is unfortunately required by some apps. microG is not a viable alternative, as it requires root access on the device, which drastically reduces the security. It also has worse compatibility than Sandboxed Play services, and doesn't offer much of a benefit. It still downloads and executes proprietary Google blobs in the background in order to function. Apps that require Google services also include a proprietary Google library, making microG essentially useless. It's an open source layer that sits between a proprietary library and a proprietary network service, using proprietary binaries and requiring root access. You gain absolutely nothing from using it, and significantly increases the attack surface of your device.
fully open source emulator
This is simply false, as I explained, only a tiny bit of what microG requires to function is open source
You're far better off using Sandboxed Play services on GrapheneOS
Calyx doesn't actually support Google Play Services or Google Services Framework. It uses microG, a sometimes buggy workaround that requires root access and has pretty poor compatibility. GrapheneOS on the other hand uses the official Google Play binaries, but isolates them in the Android application sandbox, instead of installing them as system apps with special privileges (like it is the case on stock Android). You can read more about it at https://grapheneos.org/features#sandboxed-google-play
How can it be a block? I thought graphene was like a one atom thick layer of graphite? If you want to make a block, you need to stack them, making graphite, not graphene.
In my experience, no. Since Google doesn't apply any battery optimizations in their stock OS, apart from those already present in AOSP, it makes sense that battery life is essentially the same in GrapheneOS.
But it could be used for smaller scale surveillance, like targeted at specific individuals
Why would this only be present in Pixels then? Google isn't interested in specific people. Intelligence agencies are. This would mean, that every phone in the world needs to be compromised using this sophisticated, stealthy technology, which is even more unlikely.
Not today, but recently at work, I, a DevOps engineer specializing in Linux and other Unix/Unix-like systems, was given the task of doing some admin and maintenance work on a few Windows servers...
I FUCKING HATE WINDOWS
THIS OS MAKES NO SENSE AND ADMINISTERING IT IS A NIGHTMARE
FUCK MICROSOFT!
Yeah, but it sucks, because of the heavy constraints of MV3
I don't mean to discredit your opinion, but it is pure speculation and falls in the category of conspiracy theories. There are plenty of compelling arguments, why this is likely completely wrong:
- Google Pixels have less than 1% of the global smartphone market share, in fact, they are currently only sold in ~~12~~ (the Pixel 9 is sold in 32 countries, my bad, I had an outdated number in mind) countries around the world. Do you really think that Google would spend all the money in research, custom manufacturing, software development and maintenance to extract this tiny bit of data from a relatively small number of users? I'd say more than 90% of Pixel owners use the Stock OS anyways, so it really doesn't matter. And Google has access to all the user data on around 70% of all the smartphones in the world through their rootkits (Google Play services and framework, which are installed as system apps and granted special privileges), which lets them collect far more data than they ever could from Pixel users.
- Keeping this a secret would also immensely difficult and require even more resources, making this even less profitable. Employees leave the company all the time, after which they might just leak the story to the press, or the company could get hacked and internal records published on the internet. Since this would also require hardware modifications, it's also likely that it would get discovered when taking apart and analyzing the device. PCB schematics also get leaked all the time, including popular devices like several generations of iPhones and MacBooks.
- Lastly, the image damage would be insane, if this ever got leaked to the public. No one would ever buy any Google devices, if it was proven that they actually contain hardware backdoors that are used to exfiltrate data.
Ok let's assume this is true, and US intelligence agencies have actually backdoored all US phone manufacturers. What about foreign phones? If this was true, someone the NSA is interested in could just defend themselves by e.g. buying a Chinese phone. All this effort, just to be defeated by foreign phone manufacturers? It wouldn't be worth it, which is why it's so highly unlikely.