Connection to supl.google.com despite SUPL & Location turned off

power_turtle

I analyzed the network traffic of my GrapheneOS-Phone using Wireshark.

It turns out that GrapheneOS is trying to connect to supl.google.com even though Secure User Plane Location (SUPL) is set to "OFF".

EVEN WHEN "LOCATION" IS TURNED OFF, GrapheneOS IS STILL TRYING TO CONNECT TO supl.google.com !

Changing the SUPL setting to "GrapheneOS proxy" will indeed lead to network traffic going to the Graphene proxy instead of supl.google.com.
HOWEVER, SETTING SUPL = "Off" APPARENTLY HAS NO EFFECT.

Furthermore, GrapheneOS is connecting to pool.ntp.org even though I switched off time and date synchronization.

What's going on here ?

GrapheneOS

power_turtle Which device model and OS release version are you testing? The legacy extended support releases for end-of-life Snapdragon Pixels aren't officially supported and do not receive significant internal or public testing. We did our best to provide security backports after end-of-life with minimal resources available for it via extended support and then legacy extended support releases. They're essentially unsupported now although after we're done porting to Android 16 we can go back to providing emergency releases for them.

Android Open Source Project and stock Pixel OS use time.android.com, not pool.ntp.org. If our change wasn't there you would see connections to time.android.com. It's possible you have software installed that's using NTP by itself. We replace using NTP with HTTPS network time so NTP itself isn't used. HTTPS network time can be toggled via the network time toggle, since unlike AOSP or the stock Pixel OS we don't always use it.

GrapheneOS

power_turtle We'll be shipping a minor change on the Pixel 9a today which may resolve the issue you're seeing with the "Off" mode.

power_turtle

It's a fresh install of build 20250605 on a Pixel 9a - without any apps installed.

Wireshark does not list any connections to time.android.com . Perhaps the connections to pool.ntp.org are related to AGPS / SUPL - connections to supl.google.com and pool.ntp.org seem to occur at the same time repeatedly.

I remember reading somewhere that if there's no SUPL hostname provided in the respective config file, Android will just connect to supl.google.com . Perhaps for SUPL=off to work, some dummy hostname needs to be provided in the config ?

GrapheneOS

power_turtle Pixel 9a is in a weird state where it's still based on Android 15 QPR1 due to them launching it with a Android QPR1-based device branch while other devices are on Android 15 QPR2. It's possible that there's an issue related to Samsung GNSS on the Pixel 8a and later but it may also be something Pixel 9a specific due to the weird state it was in before Android 16. We have a special device branch and special releases to support the Pixel 9a which will be replaced by mainline GrapheneOS with Android 16.

Unfortunately, the Android 16 release is delayed due to them removing device support code we used in AOSP. We would normally have Android 16 in the Alpha channel for a couple days already and also Beta by now too. Instead, we're doing internal Android 16 testing while we remake the device support we need.

ryrona

An earlier thread reporting on this same issue:
https://discuss.grapheneos.org/d/22233-odd-connections-to-suplgooglecom

That reporter stopped responding and issue was closed as not reproducible. They apparently had a Pixel 9 Pro.

I am tracking this issue as one I will attempt reproducing when I get some time to, maybe in a few weeks. But I only have a Pixel 7a, and it sounds like it maybe might be Pixel 9 specific? And also not reproducible by everyone?

GrapheneOS

ryrona Pixel 8a and later have a different GNSS chip with different drivers and services. Pixel 7a has a Broadcom GNSS chip while the later ones have Samsung.

power_turtle

Thanks a lot @GrapheneOS . In case it helps tracking down the problem: I haven't even inserted a SIM yet - it's a brand new phone with a fresh install.

I was also wondering whether GrapheneOS is sending any IDs with SUPL requests ? Android apparently sends the IMEI (!) with SUPL requests even though technically completely unnecessary.

I would recommend renaming the "Standard server" option in the SUPL menu to "Google server", so people know where they're connecting to...

GrapheneOS

power_turtle

I was also wondering whether GrapheneOS is sending any IDs with SUPL requests ? Android apparently sends the IMEI (!) with SUPL requests even though technically completely unnecessary.

We disabling sending IMSI and phone number with SUPL requests. It shouldn't send any IDs.

I would recommend renaming the "Standard server" option in the SUPL menu to "Google server", so people know where they're connecting to...

It is not specifically a Google server. The carrier can provide their own. Most carriers do not provide their own, but it wasn't originally meant to be Google providing it for everyone. The feature was meant to be provided by carriers and therefore would not be providing any information carriers don't already get through you being connected to their network. The whole point was meant to be that the carrier gives you the location of their cell towers to accelerate GNSS or even to be used as a standalone early generation form of network location separate from GNSS.

power_turtle

Interesting - didn't know about these details.

Using carrier SUPL indeed seems unproblematic.

But using Google SUPL even with IMEI / IMSI stripped out probably still allows Google to correlate requests using the phone's IP adress and logins to Google services.

Perhaps the clearest choice list for SUPL would be:

proxied Google SUPL
unproxied Google SUPL
(unproxied) carrier SUPL
off / no SUPL

Certainly an esoteric topic, but quite important for locational privacy.

Will be happy to test the update in the coming days.

GrapheneOS

power_turtle Standard mode means using the carrier SUPL but most of them choose to not provide their own so that choice is supl.google.com for Android. Some specify it explicitly, most don't. Very few actually have their own. Many carriers used to have their own but they phased it out because Google's is free for them, has better reliability and from their perspective no disadvantages. Similarly, nearly all carriers are implementing RCS via Google instead of doing it themselves. This is the way things have been headed as a whole for the internet for quite some time. It's increasingly centralized with nearly everything outsourced to a few large providers like Amazon, Microsoft, Google and Cloudflare. Even when carriers do host this stuff themselves, it's generally on AWS, Azure or GCP and often also has Cloudflare in front.

GrapheneOS

@power_turtle Please try the new Pixel 9a release available in the Alpha channel. It's meant to resolve this issue but we need you and others to test since we're very busy with the Android 16 port.

GrapheneOS

It's in Beta now too.

power_turtle

Just installed Beta 20250614.

The connections to supl.google.com are now gone when SUPL is turned off.

There are still DNS lookups for the root domain (.) going out. Connection attempts to pool.ntp.org also happen repeatedly, and they are coming indeed from the GPS-Daemon (User ID 1021).

Since no connections are made anymore to supl.google.com, this update should do the trick - great job @GrapheneOS .

Will this change be merged into STABLE soon ? Are there any issues when switching back and forth between ALPHA / BETA / STABLE ?

GrapheneOS

power_turtle There will be a new release today which will quickly reach the stable channel. There are no issues switching release channel, that just determines where you get the releases from.