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
This Tweet was deleted by the Tweet author. Learn more
Replying to
We wanted to provide the option and in order to provide the option, we need to be heavily used and tested. It would probably be best to provide an explanation during the initial setup. Google has no problem with people using this service, whether it's an OS based on AOSP or not.
1
1
Since there's a toggle and good documentation on it, we're happy with the current situation. It takes work to add and maintain more activities for the initial setup wizard. Would be open to merging an implementation of providing a choice for this with an explanation there though.
1
For network time updates, AOSP uses the mobile network or NTP if that's not available. Neither of those is secure but the fallback to NTP is particularly bad.
GrapheneOS uses time.grapheneos.org for HTTPS-based time sync.
In that case, you can just turn it off, and you look like someone getting it from the mobile network. We have a low priority issue about offering a way to use the standard approach. It's not entirely clear if we should bother with that. We do consider these issues quite a bit.