GrapheneOS is not made for nerds, it is made for normal people.

You don’t know any normal people, do you?

For what it is worth, GrapheneOS have expressed interest in a new base OS with an Android compatibility/virtualisation layer, but they do not have the resources to build it themselves and a suitable open source one does not already exist for them to leverage.

Historically, some very large Android OEMs based in China and selling in China also provided bootloader unlocking support in their devices including Xiaomi https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame... and Oppo https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame...

It doesn't have anything directly to do with GrapheneOS, and would have enabled custom OS support of any Android distribution.

Xiaomi claims to provide unlocking, but doesn't actually. I don't know about Oppo.

What if GrapheneOS believe that privacy/security is what gives users real abuse-resistant agency and control over what happens on their device with their data?

GrapheneOS is permissively licensed so that people can do exactly that (and fork for different hardware platforms) if they want to. It is a donation-supported open source project with a small team, and it is not a crime or moral failing for them to put those resources into doing the best that they can, instead of spreading themselves thin on something they cannot be motivated or proud of.

GrapheneOS have discussed and explored replacing Google Play/Google Mobile Services functionality with equivalent or open source replacements. See: eSIM management, location services, push notifications et cetera. What they have refused is bundling a privileged component (for full Google Services functionality/compatibility) and enabling signature spoofing support.

GrapheneOS also heavily promote the use of open source Android apps. What they refuse is having app stores that reuse app package names, centralise the signing of app packages, perform reproducible builds on outdated infrastructure, significantly delay app updates et cetera.

I cannot deny your opinion, but just want to suggest that from my understanding GrapheneOS are not against microG and F-Droid as concepts, just against their current implementations.

What about issue tracker discussions, mailing list discussions, security vulnerability reports etc.?

Can you report this to GrapheneOS?

It has been reported to Google (as a security bug) and to GrapheneOS as a comment in one of the very similar VPN leak issue on github. GrapheneOS has deleted my comment, probably because they assumed it was AI-generated or something, I've copied the report I sent to Google there.

It was believed to be an AI generated comment and the issue is already known. We solved it as part of VPN lockdown mode which means it isn't solved for profiles not using a VPN in lockdown mode yet. We could expand our already working approach to always be active but we were concerned about compatibility so we scoped it to VPN lockdown mode.

Since we're steelmanning, I would like to add a bit more.

GrapheneOS will never be closed source/proprietary because they believe code freedom (and user freedom by extension) is paramount. They have repeatedly said they don't have the resources to build a ChromeOS-esque firmware authentication and warning flow for ephemeral user-accessible root and support those builds alongside the existing production environment. They have NOT said it is something they have no interest in even discussing. They have also repeatedly said that where the utility is clearly demonstrated and can be architected in a maintainable way, they are open to contributions (and continued maintenance) that properly enable functions that people unnecessarily need to abuse root privileges for.

The main goal of their project is a system that can protect your personal thoughts, associations and memories to the best of its ability (against thieves, attackers, surveillance etc.) while preserving your interaction with the world. Current OSes (including GrapheneOS and iOS) are already far behind where they should be given the wealth of privacy enhancing technology, computer hardware security, systems engineering and OS design knowledge that has existed for decades- so their work is cut out for them and they are putting everything they have into leading the industry. Their hands are already full. For clear use cases the path of least resistance would be to contribute and commit to maintaining features everyone would benefit from.

If it is a feature/function someone understands they would benefit from personally but do not see the value to impose on others, we can circle back to the original fact which is that GrapheneOS is open source and can be bent/built to your will.

What functionality and features are lost in the base Pixel OS (not apps) as a direct result of GrapheneOS's changes to AOSP?

Very little if anything at all. Depends a bit how you draw the line between an app and the base OS. Contactless payments dont work with Google Pay - but that is due to Google using attestatiom to check if the OS is GMS lincesed (GrapheneOS is not). There are alternative contactless payment options that work fine.

Moving the goalposts to "it's not their fault that it doesn't work" doesn't really change it doesn't work.

There's quite a list you can get even from GrapheneOS's posts - among other things, there's a rather large set of apps that will outright crash when MTE is enabled.

Could you list a couple of the biggest functionality losses from AOSP due to GrapheneOS changes? I might be misunderstanding what you mean.