I don't think that there is a need to have these options

[deleted]

blicero If you're saying this with such confidence then might as well name some use cases for it.

Graphite

A big use case is from the "A" of the C.I.A. triad. Availability.

What happens when GrapheneOS servers go down? Users NEED the ability to fallback to stock capabilities.

Graphite

[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?

Graphite

[deleted]

It does help. Not 100% prevention. But it goes from obvious and easy to manual log review required. Don't let the perfect be the enemy of the good.

Graphite

[deleted]

How realistic is it that servers go down? In an open source project that devs are funding with donations?
Very!

[deleted]

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?

Graphite

[deleted]

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?

Eirikr70

Does anyone apart from Lukas care about these toggles ?...

Graphite

Eirikr70
No

[deleted]

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?

Graphite

[deleted]

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?

[deleted]

Graphite Even though this is an extremely niche use case, it is a use case. This can be marked as solved, I guess.

Graphite

[deleted]

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?

[deleted]

Graphite Let me try to answer those.

The possibility of their servers going down, someone getting affected by it, realising what's happened, and switching these toggles to Google before these servers go up again is very slim, at least in my opinion.
If you use a VPN or Orbot, then connectivity checks are the only connection that is happening outside the VPN tunnel. So you can disable them so no connections happen outside the VPN tunnel, or you can set it to Google to hide the fact that you're using GrapheneOS. So it's useful, and it's above the other two toggles.
I think that these two options cause confusion for users who don't know what they do or which server they should pick for little to no benefit. But that's just my opinion.

« Previous Page