[deleted]
- Edited
Blastoidea Could you name a use case for it?
I don't think that there is a need to have these options
[deleted]
No need to.
Just because you don’t think it is useful doesn’t mean it should be removed or changed.
[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.
[deleted]
Eirikr70 In my opinion, these two toggles are unnecessary and cause unnecessary confusion. But I could be wrong.
You are.
[deleted]
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.
[deleted]
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.
[deleted]
Graphite How realistic is this?
[deleted]
- Edited
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 ?...
- Edited
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?