Notices by GrapheneOS (grapheneos@grapheneos.social)

@ahrienby We aren't excluding disabled people. We've gone out of the way to do work in this area and are continuing work on it. We have limited development resources and our progress is often slow. Progress has become slower due to our lead developer being forcibly conscripted into the Ukrainian army. We can't get much done beyond maintenance right now.

We have our own fork of the open source TalkBack screen reader modernizing it, making various important fixes and making builds reproducible.

@ahrienby We want to bundle a text-to-speech implementation into GrapheneOS and it has been planned for a long time. We need to fork one with an acceptable license, make changes to it in order to make it fully work out-of-the-box and integrate it properly. We also need to integrate TalkBack into our Setup Wizard in order to provide a way to activate it at the start. There were issues with several text-to-speech implementations which slowed our progress but there may be one we can use now.

@ahrienby The post you've linked it making huge misrepresentations of our position and statements. It's presenting fake quotes as if they're things we said.

The post falsely claims we ship sandboxed Google Play as part of GrapheneOS and falsely claims that it uses system and privileged APIs. It's trying to mislead people into thinking we include that in the OS when we don't.

One of the contributors who works on GrapheneOS is blind and has been helping us improve these areas.

@ahrienby That contributor to GrapheneOS along with multiple other blind users have informed us that eSpeak NG is not really good enough to make GrapheneOS usable for them. They end up needing to use Google's Speech Recognition & Synthesis or another closed source app in practice to have a usable device. We want to include something that's actually going to be usable. It also needs to fit within our licensing, meaning it must permit commercial usage and must permit making all kinds of devices.

@ahrienby We have put hard work into this area. That doesn't mean that the end result is going to be perfect yet. There is remaining work to do forking a text-to-speech implementation, integrating that properly and adding Setup Wizard TalkBack integration. If instead of attacking us with false claims and misrepresentations, people would help us, this could potentially be done already.

It often takes us years to add features we want like the recently added network location due to high standards.

This is being done alongside Google recommending app developers forbid installing their apps from the Play Store on operating systems not licensing Google Mobile Services. The combination of these feature ends up blocking users from easily using the apps without modifying them.

We're going to add a secure way of working around this without breaking the app source security model. We'll be adding support for having the OS automatically verify the Play Store signing metadata and then inform Play services those apps were installed from the Play Store.

Android's hardware attestation API has anti-competition issues due to the official verification libraries hard-wiring the Google roots and encouraging only permitting the stock OS. However, it does fully support any other OS with verified boot and can be used with other root CAs.

It's worth noting Android has a standard hardware attestation API for verifying the hardware, firmware, OS and app. This supports alternate roots of trust and non-stock operating systems if apps choose to support it. Apps could perform stronger checks while allowing GrapheneOS.

Google's Play Integrity API is quite different and only supports verifying devices licensing Google Mobile Devices with the stock OS. It has support for enforcing installing apps from the Play Store. None of this has anything to do with security. It's purely anti-competitive.

Google Play Integrity permits highly insecure devices with years of missing High/Critical severity security patches. They pretend any device licensing Google Mobile Services is secure while running the stock OS and anything else is insecure. This is a lie to lock out competition.

Hardware-based attestation can be secure, but the way the Play Integrity API uses it is also highly insecure. It can be bypassed via leaked keys from the most insecure Android devices in the ecosystem. Secure way to use it is pinning, not trusting everything chaining to a root.

There's no security value to enforcing using devices licensing Google Mobile Services. The vast majority of those devices are highly insecure. Software-based attestation (device integrity) is also highly insecure and easy for attackers to bypass. This is only hurting competition.

Even if apps insist on doing these kinds of integrity checks, they can still permit GrapheneOS. We provide a guide on verifying GrapheneOS via hardware attestation at https://grapheneos.org/articles/attestation-compatibility-guide. They can still fall back to Play Integrity API for insecure devices without this.

Multiple prominent banking apps in Europe have already implemented support for GrapheneOS via hardware attestation. The pace of apps adopting the Play Integrity API is unfortunately currently faster than apps adding support for GrapheneOS. This is due to Google marketing it.

If you run into apps banning using GrapheneOS with Play Integrity, make a Play Store review with no links asking to stop banning a more secure OS. Next, make a customer support request linking https://grapheneos.org/articles/attestation-compatibility-guide. Multiple apps have permitted GrapheneOS due to these efforts.

A growing number of apps are using the Play Integrity API to enforce installation from the Play Store. This is clearly highly illegal anti-competitive behavior. It doesn't impact GrapheneOS users installing apps with the sandboxed Play Store but does impact other install sources.

Google has taken a similar path with the extraordinarily anti-competitive Play Integrity API, which disallows using any hardware or OS not licensing Google Mobile Services (GMS). Licensing GMS forces shipping Google apps with invasive access and limits allowed changes to the OS.

Google was already blocking competing app stores with their Advanced Protection Program required to properly secure a Google account, but now they're tying Android device security to this. Want proper encryption security via inactivity reboot? You cannot use competing app stores.

Most of the features already existed. The new ones are cloud-based intrusion logging, inactivity reboot (hard-wired to 72 hours), a new mode of USB protection and disabling auto-connect to a small subset of insecure Wi-Fi networks. Production MTE support is also essentially new.