[deleted]
- Edited
Graphite ISPs can identify GrapheneOS users by all of these GrapheneOS connections, and changing these two to Google servers doesn't change that. So as I said, I couldn't find a single use case for this.
Graphite ISPs can identify GrapheneOS users by all of these GrapheneOS connections, and changing these two to Google servers doesn't change that. So as I said, I couldn't find a single use case for this.
Eirikr70 In my opinion, these two toggles are unnecessary and cause unnecessary confusion. But I could be wrong.
You are.
blicero If you're saying this with such confidence then might as well name some use cases for it.
[deleted]
There's a big difference between inference of an operating system, based on HTTPS connections,.. and having actual certainty of an operating system because identifying information is traveling through your own servers.
Yes, an ISP can infer if they manually do forensics on connection logs between mobile devices and third party servers. But it would be much easier and a bigger privacy concern if they were the actual servers being communicated with.
Graphite I was just saying that changing these two to use Google servers doesn't help hide the fact that someone is using GrapheneOS at all.
Graphite How realistic is this?
Graphite It doesn't.
If you choose GrapheneOS server for attestation key provisioning it connects to:
https://remoteprovisioning.grapheneos.org/
If you choose Google then it connects to:
https://remoteprovisioning.googleapis.com/
If you choose GrapheneOS PSDS server it downloads three static files from:
https://broadcom.psds.grapheneos.org/lto2.dat, https://broadcom.psds.grapheneos.org/rto.dat and https://broadcom.psds.grapheneos.org/rtistatus.dat which are a cache for Broadcom's data available at https://gllto.glpals.com/7day/v5/latest/lto2.dat, https://gllto.glpals.com/rto/v1/latest/rto.dat and https://gllto.glpals.com/rtistatus4.dat.
If you choose Google server then it downloads from:
https://agnss.goog/lto2.dat, https://agnss.goog/rto.dat and https://agnss.goog/rtistatus.dat
So let's say you choose Google servers and guess what? It will be useless. Because without those connections it connects to these servers too:
https://releases.grapheneos.org/DEVICE-CHANNEL
https://releases.grapheneos.org/DEVICE-incremental-OLD_VERSION-NEW_VERSION.zip
https://apps.grapheneos.org
https://time.grapheneos.org/generate_204
HTTPS: https://connectivitycheck.grapheneos.network/generate_204
HTTP: http://connectivitycheck.grapheneos.network/generate_204
HTTP fallback: http://grapheneos.online/gen_204
HTTP other fallback: http://grapheneos.online/generate_204
randomstring-dnsotls-ds.dnscheck.grapheneos.org
How does changing those two to use Google servers helps to hide the fact that someone is using GrapheneOS? How?
Does anyone apart from Lukas care about these toggles ?...
There is a third toggle for connectivity checks. It can be set to Google or disabled completely.
We can also disable update checks as well.
That is for people who really don't want to stand out as different. Not many people have this threat model. But some do.
So you can basically switch all of these specific services back to Google. The two main use cases would be for availability in case graphene goes down, and for severe threat models in which some malicious ISP is looking specifically for graphene users.
These options don't hurt you personally. So why the crusade?
Graphite If you want to hide the fact that you're using GrapheneOS and your threat model is that high, wouldn't it make sense to use a VPN or Orbot and then set internet connectivity checks to Google to actually fully hide the fact that you're using GrapheneOS instead of disabling everything that could identify you as a GrapheneOS user, which would prevent you from getting updates for apps from Apps and getting system updates?
The VPN or Tor traffic could make you stand out too. Or could be blocked.
GOS Apps and system updates don't happen frequently enough to be a problem. For that, it's not a toggle. Disable it while out on untrusted networks, and re-enable every week or so. Some can go months in between updates.
But again, choice is good.
So you agree that the toggle between Graphene/Google for Connectivity Checks is useful?
Graphite Even though this is an extremely niche use case, it is a use case. This can be marked as solved, I guess.
Unresolved questions:
1) Is having availability in case graphene servers go down, not a significantly, non-niche use case?
2) Do you consider the toggle for connectivity checks to be good to have, compared to the other two?
3) The most asked question left unanswered. Why do you care?