The service was blocking our grapheneos.network connectivity check server for a period of time yesterday/today. It was unblocked after users reported it. It's very strange and I think it reflects quite badly on their processes for blocking supposed malware domains.
Conversation
I'd really like to know why a domain using DNSSEC and running an HTTP / HTTPS server serving empty 204 responses for /generate_204 was blocked.
It doesn't serve anything else beyond redirects to grapheneos.org/faq#default-co for /, a static MTA-STS configuration and 404 responses...
1
2
The grapheneos.online domain wasn't blocked but we hadn't yet started using it for one of the fallback URLs.
If you run into a similar issue with content filtering, you can use the toggle we added to use the standard Google servers for connectivity / captive portal checks.
1
2
Enumerating badness is not just an unworkable approach but inflicts serious collateral damage. Have had multiple users fall behind on updates, etc. from these kinds of issues. Drains development time too.
Safe Browsing and assorted content filtering lists have the same issues.
2
This Tweet was deleted by the Tweet author. Learn more
Replying to
For the case where you aren't using a VPN, you already need to disable network time updates and OS updates in order to avoid being identified as running GrapheneOS.
If you're using a VPN, then the connectivity check toggle is the only change that's needed to blend in properly.
1
The default is always open to being changed in the future. It's difficult to provide the service properly if we don't have a lot of users testing it. Issues like this Quad9 DNS false positive wouldn't get detected. We could add a choice to the setup wizard in the owner profile.
Perhaps it would be best if users were given a choice during the initial setup with an explanation that if they use a VPN and standard connectivity check URLs they blend in with other Android users for network operators. Blending in from VPN provider perspective requires more.