latest build (android14)
settings -> location -> Secure User Plane Location

HTTPS connections are made to fetch PSDS information to assist with satellite based location. These are static files and are downloaded automatically to improve location resolution speed and accuracy. No query or data is sent to these servers.
https://grapheneos.org/faq#default-connections

No data except IP address and linux kernel as @de0u already answered me, right ? Hence the offer of gOS proxy ?
What could be the delay from using such proxy ? Milliseconds or seconds? Or does the proxy really serve only once anyway, for downloading attestation/DRM/GPS' almanac ?

    graphenediscoverer4 No data except IP address and linux kernel as @de0u already answered me, right ?

    In practice you may be leaking your device model too, since I have a faint sense that the GPS firmware in different Pixel devices requires satellite data in different formats.

    graphenediscoverer4 What could be the delay from using such proxy ? Milliseconds or seconds?

    I don't think the satellite orbit data change very often (maybe not every day), and GPS receivers are designed to work around slightly stale data. I also think GrapheneOS fetches the data only intermittently (i.e., does not stream it continuously). So I don't think delay due to the proxy would have any observable effect.

      graphenediscoverer4

      It looks like there is a cache. Our phones would just download the .dat or .bin files, depending on the phone model, and go from there. I wouldn't worry about any delay. I just manually downloaded the Broadcom ones and the total size was 184 kb (Pixel 6 and later). The Qualcomm one was 64 kb. Regardless, they're all very small so downloading them shouldn't take much time at all even with a slow connection.

      According to this page, there are 4 of these servers in different locations which, according to an IP address lookup website, are Canada, the US, France, and Singapore to reduce latency.

      Here's the nginx configuration file: https://github.com/GrapheneOS/grapheneos.network/blob/main/nginx/nginx.conf#L344

      graphenediscoverer4 linux kernel

      I don't think so. The only info I can think of would be: IP address and whether the phone is Pixel 6 or newer vs older than the Pixel 6.

      There's a relevant section of the website here: https://grapheneos.org/faq#default-connections. Just scroll down to the bullet point that starts with:

      HTTPS connections are made to fetch PSDS information to assist with satellite based location.

        de0u

        other8026

        Thank you very much guys, few last questions :

        1. When the docs says :

        GrapheneOS improves the privacy of Qualcomm PSDS (XTRA) by removing the User-Agent header normally containing an SoC serial number (unique hardware identifier), random ID and information on the phone including manufacturer, brand and model.
        https://grapheneos.org/faq#default-connections

        I don't find it in the code https://github.com/GrapheneOS/grapheneos.network/blob/main/nginx/nginx.conf#L344
        Is it what proxy_hide_header X-Robots-Tag; and proxy_hide_header X-Amz-Cf-Id; mean ?

        1. Docs don't write about removing information when forwarding the request of getting the GPS almanac to broadcom (even though I see some proxy_hide in the codeblock dedicated to broadcom too), does this mean there are some leakages on latest devices, or that broadcom doesn't gather any sensitive info ?

        2. If A-GPS ("Secure User Plane Location (SUPL)") is disabled,

        A-GPS is extensively used with GPS-capable cellular phones, as its development was accelerated by the U.S. FCC's 911 requirement to make cell phone location data available to emergency call dispatchers. https://en.wikipedia.org/wiki/Assisted_GNSS

        Will emergencies still be able to retrieve my position if I do an emergency call ?

        1. Does enabling "Predicted Satellite Data Service (PSDS" only download the GPS almanacs at some developper-preset period, or only when gOS broadcasts them, or can it make the handset eager to emit a request ("i want to obtain the almanacs") when the user fires up the GPS sensor / opens an app needing GPS ?

        2. For pixels6+ :

        https://broadcom.psds.grapheneos.org/rtistatus.dat which are a cache for Broadcom's data available at https://gllto.glpals.com/rtistatus4.dat. Alternatively, the standard servers can be enabled in the Settings app which are https://agnss.goog/rtistatus.dat providing a similar cache of Broadcom's data currently (as of October 2022) hosted on GCP (Google Cloud Platform).
        ( https://grapheneos.org/faq#default-connections )

        Why gOS proxy fetches almanacs from broadcom servers but not using the gOS proxy would kind of use a google proxy, instead of directly fetching from broadcom ?

          1. https://en.wikipedia.org/wiki/Assisted_GNSS seems to say that A-GPS/SUPL speeds up the fix obtention way more than PSDS/Almanacs possession does. Do you guys relate to this ? (For me to know whether it's really worth it to expose that the user fires GPS to the nearby celltowers/routers = ISP = gowvernment ... = )

          2. What is the server called "standard"/the server to which gOS connects to, for A-GPS/SUPL ?

            graphenediscoverer4 When the docs says :

            GrapheneOS improves the privacy of Qualcomm PSDS (XTRA) by removing the User-Agent header normally containing an SoC serial number (unique hardware identifier), random ID and information on the phone including manufacturer, brand and model.

            I don't find it in the code https://github.com/GrapheneOS/grapheneos.network/blob/main/nginx/nginx.conf#L344

            There's lots of code, all over the place! My naive reading of the text quoted is that the GrapheneOS developers changed code on the device to suppress the SoC serial number. I don't think it makes sense to assume the suppression must be happening in the GrapheneOS proxy.

              graphenediscoverer4 If A-GPS ("Secure User Plane Location (SUPL)") is disabled [...] will emergencies still be able to retrieve my position if I do an emergency call ?

              Disabling any part of the location system will degrade the accuracy of the system, but the other parts will still work. Even if the device has no idea where it is, the cellular carrier can still estimate location from towers.

              graphenediscoverer4 I don't find it in the code https://github.com/GrapheneOS/grapheneos.network/blob/main/nginx/nginx.conf#L344
              Is it what proxy_hide_header X-Robots-Tag; and proxy_hide_header X-Amz-Cf-Id; mean ?

              Based on this documentation on Nginx's website, it appears that the headers are dropped when passing the response to the client, which would in this case be our phones.

              graphenediscoverer4 Docs don't write about removing information when forwarding the request of getting the GPS almanac to broadcom (even though I see some proxy_hide in the codeblock dedicated to broadcom too), does this mean there are some leakages on latest devices, or that broadcom doesn't gather any sensitive info ?

              The website specifically mentions Qualcomm, but not Broadcom, so I would guess that means that info was never never included in the request in the first place.

              graphenediscoverer4 If A-GPS ("Secure User Plane Location (SUPL)") is disabled,
              graphenediscoverer4 Will emergencies still be able to retrieve my position if I do an emergency call ?

              I haven't looked at that code in a long time, but I don't recall there being anything in GrapheneOS's implementation for disabling SUPL that would affect any other part of the OS or change its behavior. That said, I could be remembering wrong, of course.

              graphenediscoverer4 Why gOS proxy fetches almanacs from broadcom servers but not using the gOS proxy would kind of use a google proxy, instead of directly fetching from broadcom ?

              I don't understand this question. You have already read through the Nginx configuration file. You can easily find out where the proxies fetch the files from.

              graphenediscoverer4 https://en.wikipedia.org/wiki/Assisted_GNSS seems to say that A-GPS/SUPL speeds up the fix obtention way more than PSDS/Almanacs possession does. Do you guys relate to this ? (For me to know whether it's really worth it to expose that the user fires GPS to the nearby celltowers/routers = ISP = gowvernment ... = )

              I don't understand parts of this question as well. I have disabled SUPL on my phone before and don't really recall my phone getting a location being that much slower. Feel free to disable it on your phone and try it out.

              graphenediscoverer4 What is the server called "standard"/the server to which gOS connects to, for A-GPS/SUPL ?

              The PSDS servers are listed on the website. The default SUPL site is probably supl.google.com:7275, but I didn't confirm that in the OS code. That's the server listed in the Nginx config for the SUPL proxy, so I'd assume that's the default used if not using the proxy on our phones.

                graphenediscoverer4 Does enabling "Predicted Satellite Data Service (PSDS" only download the GPS almanacs at some developper-preset period, or only when gOS broadcasts them, or can it make the handset eager to emit a request ("i want to obtain the almanacs") when the user fires up the GPS sensor / opens an app needing GPS ?

                I have a faint sense that you may believe it is important for your device to have up-to-the-minute PSDS data. But I believe (de0u) the PSDS system is designed to work well with PSDS data that is multiple days old. If you believe your device would benefit from "eagerly" fetching PSDS data, could you please provide a link to a reliable source supporting "eager" fetching of PSDS data?

                  other8026 I don't understand this question. You have already read through the Nginx configuration file. You can easily find out where the proxies fetch the files from.

                  gOS proxy fetches the files at the source, being broadcom. So on our devices, standard server should be broadcom. Instead it's google, who also fetch the source at broadcom...

                    de0u I have a faint sense that

                    No I understood that PSDS is always already outdated. From what I understand, the phone needs 2 components, almanacs that are broadcasted by terrestrial servers, and ephemerides that is retrieved by the phone from the satellites. I guess enabling A-GPS just serves the ephemerides component to the handset way quicker than the satellites (which broadcast at 50bit/s), or maybe even both ephemerides + latest almanacs, i don't know.

                    My concern apart from a quick fix, is to not leak that I'm firing up the GPS sensor at time T, revealing that user is probably about to make a move.

                      • Edited

                      graphenediscoverer4 From what I understand, the phone needs 2 components, almanacs that are broadcasted by terrestrial servers, and ephemerides that is retrieved by the phone from the satellites. I guess enabling A-GPS just serves the ephemerides component to the handset way quicker than the satellites (which broadcast at 50bit/s), or maybe even both ephemerides + latest almanacs, i don't know.

                      I don't believe that understanding is accurate. In particular, A-GPS is a dynamic carrier service, not static data. See, for example: https://www.cisco.com/c/en/us/td/docs/routers/access/800/829/software/gps/Assisted-gps.html

                      graphenediscoverer4 My concern apart from a quick fix, is to not leak that I'm firing up the GPS sensor at time T, revealing that user is probably about to make a move.

                      I believe those concerns are opposed.

                      Occasionally fetching mostly-static PSDS data supports GPS. The fetching is designed to be infrequent and the GrapheneOS changes and proxy, as documented, should provide good privacy.

                      SUPL improves speed and accuracy a lot more, but probably leaks location data to a service provider. Even if your device is anonymized to some extent by a proxy, location tracking somewhat de-anonymizes it.

                      That said, if your device has its cellular modem on it is already leaking a location track, because that's how the cellular network is designed to work.

                      The baseline GPS system provides pretty good localization with strong privacy (it's receive-only). Anything beyond that leaks information. In the case of PSDS as implemented by GrapheneOS the leakage is likely minimal. Leakage for SUPL may well not be minimal.

                      Edit: But the baseline GPS system is slow, and it needs to see lots of satellites, hence SUPL (and also Google's Wi-Fi AP localizer).

                        de0u https://www.cisco

                        Crap :( "Access Denied" to browse the internet I use proxies so I was never able to browse cisco pages, I hate them for that... If you don't mind uploading a screenshot here or imgur (or any pic hosting website) of the article, I'd be interested, as I'm pretty convinced you have a better understanding of AGPS than mine...

                        de0u cellular modem

                        Thanks for reminding me that AOSP/gOS devs didn't revert to the pre-android12 era where cellular and wifi quicksettings were distincts, I will create a dedicated thread on this forum shortly

                        • de0u replied to this.

                          graphenediscoverer4 I use proxies so I was never able to browse cisco pages, I hate them for that... If you don't mind uploading a screenshot here or imgur (or any pic hosting website) of the article, I'd be interested, as I'm pretty convinced you have a better understanding of AGPS than mine...

                          I selected the Cisco page pretty much at random. There is lots of material online about AGPS. The Wikipedia page, though not very detailed, does mention Google's SUPL in particular.

                          I think probably the way to look at it is:

                          • If you want to blend in with Google Pixel users, use the regular PSDS service, which is probably leaking very little about you due to the GrapheneOS on-device fixes,
                          • If you want to conceal your IP address from Google and are willing to disclose it to the GrapheneOS proxy, use the GrapheneOS PSDS proxy,
                          • If want "actual GPS" anonymity (slow location fixes without any transmission), turn SUPL off,
                          • If you want fast fixes and are willing to leak some IP-address information and possibly position information, turn SUPL on and decide who you would prefer to leak to.
                          • If you want really fast fixes even when you are completely indoors, run Google's stock OS, which uses their database of Wi-Fi access points, but serves as a data-collection platform for Google

                            de0u If you want really fast fixes even when you are completely indoors, run Google's stock OS, which uses their database of Wi-Fi access points, but serves as a data-collection platform for Google

                            Is this the only solution for indoor fixes, I mean the stock OS?
                            I asked in the past that I would like to achieve this on Graphene OS - https://discuss.grapheneos.org/d/10392-indoor-location

                            • de0u replied to this.

                              SUPL is only used when cellular is enabled and there's an active carrier. SUPL has multiple modes and the normal mode that's used by GrapheneOS doesn't leak much information. It downloads a database without submitting much data. It leaks your carrier to the server to get a database for that carrier. SUPL in the more aggressive mode can be used to determine location by itself but that's not available as a toggle in AOSP or the stock OS so it's not there as an option in GrapheneOS either. The more aggressive mode would leak your location to the SUPL provider.

                              PSDS downloads are static databases and can be cached for a long period of time.

                              graphenediscoverer4 No, the standard server for Pixels is the Google server, not Broadcom.

                              graphenediscoverer4 GNSS works fine without PSDS or SUPL. PSDS and SUPL make it obtain a location fix much faster. It works without them, but very slowly if neither is available. PSDS is quite important for it to obtain a fix in a reasonable amount of time which only requires a network connection to retrieve static databases while SUPL is a bonus making it even faster. PSDS lasts for a long time before it's fully expired. You can go days without network access and it can still provide useful data to speed up the location fix.

                              de0u It's on the device where sending IMSI and phone number for SUPL was disabled, and similarly disabling sending metadata for Qualcomm PSDS. Qualcomm devices are nearly all obsolete so that's not particularly relevant anymore. Only the Pixel 5a still has privacy/security updates. You won't have privacy or security on an end-of-life device and being concerned about all these details doesn't make any sense for them.

                                GrapheneOS It's on the device where sending IMSI and phone number for SUPL was disabled, and similarly disabling sending metadata for Qualcomm PSDS.

                                Thanks for the clarification!

                                Any time unnecessary device identifiers can be suppressed that's a good thing.

                                  de0u IDs aren't sent to any service used by GrapheneOS and aren't available to regular apps, so only explicitly used OS functionality such as eSIM activation can result in them being sent to a service. The standard user agent for URLConnection does include device model and BUILD_ID. We make sure that the BUILD_ID matches the current stock OS release by overriding it when we use a newer AOSP revision than the stock OS to avoid fingerprinting based on that. It would be better if it was omitted from the user agent altogether but omitting it ourselves would likely be worse than making it match the stock OS due to the deliberately small number of supported devices for GrapheneOS.

                                  Additionally, using Google's network location service on GrapheneOS is fully supported as part of sandboxed Google Play but requires several configuration steps. By default, location requests to Google Play are rerouted to the OS location service.

                                  We don't currently offer a toggle for the OS to use it as an OS network location service, which is how it works on the stock OS, where using network location via the OS location API results in querying Google Play. We do the opposite by default, where querying Google Play instead queries the OS. We could provide a 3rd value for the toggle to do what the stock OS does. However, most apps from the Play Store which use network location query Google Play for it rather than the OS so their network location support works fine on GrapheneOS already.

                                  We plan to provide alternative network location services in the future, but UnifiedNLP does not suit our needs for multiple reasons. It should not be tied to Google Play compatibility. We already provide a better system for providing Google Play location API compatibility for regular OS network location services and location in general.

                                  GrapheneOS emulates network location so apps only using network location without the ability to use regular GNSS location can still work, but you may need to use an app like GPSTest to bootstrap them.