The Network location feature is a significant usability improvement for me, and I suspect for a lot of other people. I heard you're planning to add a toggle for it in the setup wizard, which I think is a good idea because a lot of users who don't follow the release notes probably don't know it exists.

    What is this "network location" thing, and how do I make sure its disabled so it doesn't share any kind of data with apple?

      secrec
      In the Owner profile, Settings > Location > Location Services > Network Location. It should be off by default, but Graphene does have a proxy option if users don't want to use Apple.

        Pixelpioneer88 Go to Settings > Location > Location Services > Network Location.

        You can choose between our proxy to Apple's location service, or connecting directly to Apple's service.

        For network location to work, you either need to have Wi-Fi on, or enable Wi-Fi scanning. Wi-Fi scanning allows the feature to work without Wi-Fi needing to be on.

        If you were previously using Google's network location feature, you'd need to first undo the steps you took to enable that.

          Dumdum Thank you. The proxy idea is interesting, but presumably it must still share a scan of SSID's, signal strengths, and location through to the destination server. That potentially tells apple even more information than they would have with a direct connection, such as "there is a grapheneos user at this location".

            matchboxbananasynergy
            Fair enough. What exactly is the difference between Network location on the bluetooth/wifi scanning by the way? Does Network location just pull them all together as a kind of Super Location Scanner?

              Pixelpioneer88 It's for when you're inside, or there's clouds obstructing your view to the sky, or a way to conserve power (more efficient than just using satellite).

              There are many apps that use location that someone would use almost exclusively indoors, such as dating apps, and network location allows you to get a location lock in that setting.

                Dumdum The bluetooth and Wi-Fi scanning toggle allow scanning while Wi-Fi and Bluetooth is otherwise disabled. That toggle doesn't do something by itself other than that. The network location feature is what's improving location accuracy indoors.

                  I noticed that my location (while inside) is seemingly jumping around (a few meters every second) was hoping this update would solve that issue but I seem to be getting the same result. There are many wifi APs nearby as I live in an apartment and I am indeed on version 2025032500 and noticed the issue on past versions as well. Outside the location works perfect and is very accurate and stable though.

                  Video: https://files.catbox.moe/6cpu59.mp4

                    matchboxbananasynergy
                    Sure, but the Wifi and BT scanning says it is used to improve location based features which gives the impression that they work similarly. Is it just inaccurate descriptions then?

                      secrec It does not share signal strengths or location. It's a different approach than Google's location service. It fetches location data for the 15 strongest signal strength APs based on their BSSID and stores that data in a local cache. We also ask for up to 100 nearby APs covering a large area to help fill the cache. The position estimation is local. We're going to be making our own database initially based on Apple's data and using that to create our own service with full offline support through downloading data for an arbitrary area. See https://discuss.grapheneos.org/d/21244-grapheneos-network-based-location-service-improvements for more information about how the current implementation works.

                      Dumdum Wi-Fi scanning and Bluetooth scanning toggles are standard Android features and are **not specific to the OS provided network location service. The toggles solely exist to allow scans while Wi-Fi and Bluetooth are turned off, but making that not really fully off but rather only for scans triggered for location purposes. Any app with the Location permission granted by the user which requests the relevant low-level Wi-Fi permissions can do throttled Wi-Fi scans. The OS location service just doesn't get throttled for battery saving reasons. Similarly, any app granted Nearby Devices by the user can do filtered Bluetooth scans, or unfiltered Bluetooth scans if they have both Nearby Devices and Location (for legacy apps, this only requires Location, they split it for modern apps to allow filtered scans with a less scary sounding permission).

                      secrec The proxy idea is interesting, but presumably it must still share a scan of SSID's, signal strengths, and location through to the destination server.

                      I think the client presents a list of SSIDs and Apple provides their locations. It is not clear why the client would provide relative signal strength information. Apple can infer a location to some extent, but presumably less well than the client.

                      secrec That potentially tells apple even more information than they would have with a direct connection, such as "there is a grapheneos user at this location".

                      There are other options... Google's service... GNSS... waiting for the GrapheneOS client to support cell-site info...

                      Reproach3656 It's normal for it to jump around. It's partly because it's currently using RSSI (signal strength) for distance estimation. It will get less jumpy when we add support for using Wi-Fi RTT (Round-Trip-Time) for distance estimation. Signal strength varies a lot and that means the estimated distances to Wi-Fi networks varies a lot which can impact the result a lot. Wi-Fi RTT and batching the requests more are the only planned major improvements to the Wi-Fi part of it in the near future. Cell tower fallback will be added, but that's separate from how it will usually work in most situations in a city. Making our own database for a non-proxy service and offline support are other major improvements planned for it.