Notices by GrapheneOS (grapheneos@grapheneos.social)

@luc Many apps do hard-wire IP addresses as a fallback such as certain Facebook apps. It may also be the primary way they connect. They can hard-wire DNS-over-HTTPS IPs and use their own DNS resolution for everything else.E ven if this wasn't the case, you're not going to be using apps if you've blocked the services they need to function. Unless the apps don't depend on any non-user-selected services, what will be accomplished? They can and do connect to third parties from their servers.

@luc You do not need app accessible root access to filter DNS requests or network traffic beyond that. However, you are not going to provide any substantial form of privacy through using block lists enumerating badness. Those can only block looking up DNS names which are solely used for unwanted things and not useful things. Services combining those together prevents this being done since you aren't going to be using apps if you're blocking the services they use. The approach does not work.

@luc Many people wrongly believe they can prevent sharing with third parties through filtering on the client side. That won't work if you're letting them connect to anything else, especially their own services directly.

There are also many apps using DNS itself as a 2-way communication system. DNS resolution itself allows communicating to the nameservers for a service through your DNS resolver server. It's a full blown 2 way communication system. Can include a random value to bypass caching.

@luc You can use RethinkDNS on GrapheneOS for filtering DNS in combination with using a WIreGuard VPN or multiple chained WireGuard VPNs. However, just be aware that the privacy benefits from filtering DNS or IP-based filtering are limited. You're limited to blocking things not required for apps to function, i.e. you cannot block the core privacy invasive behavior of apps and how they share with third parties from their services including long after the fact based on the data they gathered.

@luc If you want privacy, you need to focus on what you share with apps and services, not which IP addresses or DNS names can be used. That isn't going to provide real privacy protection, it's just a best effort way to eliminate some things which are easy to cut out without losing functionality. The idea that it provides substantial/fundamental privacy protections is wrong. Features like our Contact Scopes, Storage Scopes, Sensors toggle and standard Android privacy features are what you need.

@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.