supl.google.com

John443

I'm recording dns attempts to supl.google.com, typically at the same time as google.psds.graoheneos.org.

Using PCAP, I see that "Android" or "GPS" are the apps trying to send this communication to Google.

Why is there a communication to Google and how do I stop that? I can't access the hosts file in Grapheneos...

matchboxbananasynergy

Hi there, please take a look at this section of the FAQ:

https://grapheneos.org/faq#default-connections

The latter is not Google, but rather GrapheneOS, through which the PSDS data is being proxied.

If you go to Settings > Network & Internet > PSDS server, you'll see that the default is the GrapheneOS proxy with the option to use the standard Google connection instead.

On supl.google.com:

https://github.com/GrapheneOS/os-issue-tracker/issues/96
https://github.com/GrapheneOS/os-issue-tracker/issues/914
https://github.com/GrapheneOS/os-issue-tracker/issues/915

I hope this helps!

John443

matchboxbananasynergy

Thanks for the info. Yes, I'm clear about google.psds.grapheneos.org.

My issue is supl.google.com. I read the 3 articles and my takeaway is 1) I clearly see a connection going through my pihole, but issue 96 claims "You can already verify that the OS makes no connections to supl.google.com". I'm not sure how to reconcile the "no connection" with what is captured by my pi-hole. 2) issue 915 acknowledges that "a SUPL request done with a phone that has no IMSI sends an IMSI value of 0" but there is nothing to worry about. We just have to trust that there is really a value of 0 sent (I wouldn't know how to audit myself).

Seems like a confusing issue. Given that Google is in the business of knowing everything about everyone - and they most certainly have the tools to de-anonymize a lot of Grapheneos users out there - I would feel much more comfortable knowing that there is exactly zero connection made to Google. Explicit, as in nothing is seen in my Pi-hole.

Of course I can dns filter, but 127.0.0.1 supl.google.com at system level is simply better.

I support the request for a toggle! Chers

John443

Hopefully an expert can bring additional clarity on this. Will be much appreciated

GrapheneOS

Your carrier is configured to use Google's SUPL server. There is no carrier in the default install without inserting or activating a SIM.

John443

GrapheneOS
So I recently switched from IOS to Grapheneos. On IOS there was no connection to supl.google.com. Is it really the carrier then? A toggle to intercept both supl.google.com and google.psds.grapheneos.org would be great.

f13a-6c3a

Per this twitt:
https://twitter.com/GrapheneOS/status/1601367470639808512?s=20&t=IufHte4n7iTmSFujRlox0Q
"Default SUPL server is http://supl.google.com but carriers can choose the implementation. If you don't want SUPL being used, you simply have to delete supl from your APN types."
and
"Yes, that disables SUPL, which is either using the default http://supl.google.com or a carrier provided SUPL configuration. Carriers aren't providing their own SUPL servers in practice since control plane A-GNSS exists. You may also want to remove dun"

Changed "APN type" from:
default,supl,dun
to:
default

enduring78

Did anyone test to see if the requests are really gone after removing 'supl' from the APN type?

It worked before, but somehow after the Android 13 QPR1 update (or around that time) the APN type was automatically set back to 'default,supl'. OK, I thought, let's remove it again. The APN type still says 'default', yet the supl requests are still made in a regular interval even after toggling airplane mode and a reboot.

Does anyone know what is going on here?

AloofChocolate

Here is a piece on the supl.google.com problem. dating back to 2017, my pi-hole is showing the supl.google.com problem and I don't have a carrier install as of yet for the graphenos.

https://forum.xda-developers.com/t/keep-a-gps-supl-disabled-upon-rom-install.3612024/

matchboxbananasynergy

Quick update to this:

https://grapheneos.org/releases#2023021000

add toggle to Settings ➔ Location for force disabling SUPL as a carrier-independent replacement for editing APN configuration since editing APN configuration is unintuitive, not fully respected on Tensor SoC devices and users with no carrier should be able to disable it without using airplane mode

[deleted]

matchboxbananasynergy Hi, I don't really understand what the new SUPL toggle is for and I don't know what SUPL is either?

Azerick

[deleted]

Same. No idea what disabling it does (or breaks)

[deleted]

Hi guys, I'm new to Graphene so I'm not very familiar with the system.
Should I leave the item under Location (Force disable Secure User Plane Location SUPL) enabled or rather disabled?

Can enabling this option corrupt or crash something?

Hat

SUPL is a protocol for assisted GPS to find your location faster downloading some data.

"Force disable Secure User Plane Location (SUPL)" :
If OFF your data could be sent to Google but with no personal carrier info.
If ON the SUPL service it's not used, your GPS will be a little bit slower to find your location.

[deleted]

Hat

Thank you very much ! :)

[deleted]

[deleted] Sorry but I still don't understand the interest of forcing the deactivation or not of SUPL

[deleted]

[deleted]
It doesn't matter. If you are fine with the default settings, leave it as it is. The point is that some people try to avoid any connections to Google, and this new toggle can mitigate one of such a connection/ communication channels.

GrapheneOS

We now override the server to our supl.grapheneos.org proxy by default and the disable toggle was replaced with a choice between our proxy, the standard server chosen by the carrier (usually supl.google.com fallback) or disabled.