Fartimoji Our network location feature provides an opt-in toggle for detecting location based on retrieving the location of nearby Wi-Fi networks from a service. Compared to satellite-based location (GNSS), this is much more power efficient, quicker to get an initial estimate and works where there isn't satellite reception. We provide a choice between Apple's services and a GrapheneOS service proxying to their service. We're building our own database of Wi-Fi networks and cell towers in order to provide our own service. Our service will also have offline support added to it similar to how you can download maps for Organic Maps to use offline. You'll be able to download a database of Wi-Fi networks and/or cell towers for an area from our service for offline usage.

Network location is a standard feature in iOS and Android with Google Mobile Services integration. People are used to having it enabled and expect location to work indoors, etc.

Most apps support network location via the fused location provider able to use both satellite-based and network-based location. However, apps choose the power mode they want and most use a low power mode where satellite-based location won't be used unless needed. This is why it can save a lot of power. Many apps are written to assume network-based location is available and don't want long enough for satellite-based location to get an estimate. This means having it improves app compatibility.

It was already possible to use Google Play's network location on GrapheneOS for apps which use the Google Play location service directly, but now there's going to be little reason to use that since people can simply use ours. Using the Google Play network location service required multiple steps: disabling the sandboxed Google Play location rerouting toggle to have apps using it directly send their requests to it instead of the OS, enabling background Location for Google Play services and enabling their network location service through their menu for it. Wi-Fi and Bluetooth scanning toggles are also relevant in the same way Wi-Fi scanning toggle is relevant to our service (just read the description, it just makes it so apps with Nearby Devices / Location can do scans when Wi-Fi / Bluetooth are otherwise off).

      GrapheneOS We provide a choice between Apple's services and a GrapheneOS service proxying to their service.

      Why ? Why not give only the option of GrapheneOS proxy, or only Apple ?

          IamZorro Doing it this way is consistent with how we provide other options for e.g. SUPL etc.

          We provide the option to connect to the service itself, or having it proxied through us, which is going to be the default.

          The proxy avoids having you connect to the service directly which can provide some privacy benefit if you trust GrapheneOS more than the service itself, but another perspective is that if you want to minimize the parties involved when connecting to a service, doing so directly is the best way to do so.

              GrapheneOS This does not break the anonymity of a VPN.

              Yes it does, if GrapheneOS proxy is compromised. If all services where secure and trusted, you wouldn't need to use a VPN for anonymity. Each service would protect your anonymity, and HTTPS during the transport. We use VPNs for anonymity, specifically because we acknowledge any service might be compromised or forced to hand over logs at any time.

              Claiming a VPN still provides anonymity, because the location request is encrypted with HTTPS to a pinned certificate, would assume ultimate trust or inability for the GrapheneOS proxy server to be compromised, legally or technically. This is simply not a reasonable assumption to make.

              GrapheneOS Your claim would also apply to using online maps app to search for a route from your house to somewhere else or giving location data to any other service.

              Yes! It would! You mustn't reveal to the other end of the VPN what your physical location is.

              That is why you never put apps that reveal your identity over a VPN. That is why you always let banking apps, map apps, real-life social media apps and so on go out to the network directly, without going through any VPN. As it would ruin your anonymity is you let those go over the VPN. And it would be pointless to make them go over the VPN anyway, as those services would know anyway exactly where you are or who you are.

              This is a key point in compartmentalizing ones life into security domains. Your anonymous activity must not be mixed with your real life activity in any sense.

              GrapheneOS We're very clear about how network location works and it's not enabled by default so there is no need for concern about this. It will also support offline usage which is being actively developed.

              I have been thinking some more about this. Actually, it is like you are implicating not only the network location provider service that has this issue. Any app with access to your location, that is, any app with Location or Nearby Devices permissions, might leak your location. So, the only safe way is to disable location functionality completely in the profile where you have your anonymous activity and your VPN. When I think about it, I guess most people with serious anonymity needs would actually disable location services. It is asked for during setup wizard, and it is easy to understand that location would conflict with anonymity goals. So maybe a warning for the network location provider functionality is not as important as I was initially thinking.

              It might still be a risk, if the user uses the owner profile for the anonymous activity, and a secondary user profile for the non-anonymous activity with location enabled. Because as far as I understand, in this case, the location requests from the non-anonymous user profile will still be bridged onto the VPN in the anonymous user profile, which might be totally unexpected and non-obvious.

              But even then, I guess most users would naturally not choose to use the owner profile as the anonymous one, as one often want to have the anonymous one more locked away than the non-anonymous one. Still, I do think all this is worth thinking about. That location requests gets rerouted to the VPN of another profile might also be considered unexpected.

              Usable security.

                      matchboxbananasynergy I'll get that. But why not just copy Apples database (now if it's non copyrightable) and host it yourself rather then just rerouting Apple's services through GrapheneOS servers?
                      Nomatter, I see that GrapheneOS own location services is in the works.

                          VEECCdYKYi We've made it clear that we're making our own database based on Apple's data. Scraping Apple's data for Wi-Fi APs will take a lot of time and work. Making our own database and software for using it is a whole lot more work that's going to take a while. Providing offline support is a whole lot more work on top of that. We're working on that. We've said we're doing it.

                            ryrona Every profile has their own VPN configuration for a reason. Owner user VPN is used for system services. If you want to keep things more separate, then you should use multiple profiles with their own VPNs configured. It can be the same VPN provider and the same account, or you can split it up at a higher expense. That is the way to deal with these things. Our network location service is not breaking the anonymity of using a VPN, it's just a typical location-based service, is opt-in and is very clear about the fact it will send location data (nearby Wi-Fi APs) to the enabled service. There will be offline support for people willing to download a database to their storage for the areas they need. What we've provided is already a huge step towards offline support due to how Apple's API is designed. You should look at how it works. It already calculates the position estimate locally based on the downloaded Wi-Fi AP data. It only needs the service to obtain the data. With offline support, it will have a local database to query for Wi-Fi APs and can use exactly the same code for calculating the position as it uses for the online mode without a local database. It even already implements a local in-memory cache with 15 minute expiry so it can work offline to an extent after it puts data in the cache.

                                GrapheneOS Owner user VPN is used for system services.

                                It all makes sense at a technical level it is designed the way it is. All I am saying, it is not obvious to the user that is how it works. It wasn't even obvious to me, I had to ask you. So it will absolutely not be obvious to your average activist or journalist. That is why I ended my message with "usable security". That is the context in which my criticism should be viewed. It isn't obvious to users that sending your network location over a VPN compromises your anonymity either.

                                Best way to protect users from harming their own anonymity would be to assume they have zero technical knowledge of the system, and then make it easy for them to set things up the right and secure way, and hard for them to set it up the wrong way. Clear and concise warnings goes a long way to accomplish this.

                                    GrapheneOS I am a bit confused in how to use this. Going to Location->Location Services->Network Location allows me to turn it on. It says it uses WiFi scanning to help find your location. Does that mean I need to turn on Location->Location Services->Wi-Fi scanning for this to work? What is the point of bluetooth scanning if network location only uses WiFi scanning?

                                        n2gwtl additionally, I use owntracks for providing my location to other apps. Own tracks is set to record location only during significant changes to position. I am not sure how this works, but I assume the OS is indicating to the app that a significant change in position has happened which triggers owntracks to request the location. This works mostly fine with network location off. When network location is set to GrapheneOS, owntracks is requesting location every 3-10 mins even when it is on a table for 8 hours.

                                          13 days later

                                          @GrapheneOS referencing this again as I believe this got lost during the major Android quarterly update work.

                                          n2gwtl If you enable network location by itself, it will work when Wi-Fi enabled. If you enable Wi-Fi scanning, it will also be able to do Wi-Fi scans when Wi-Fi is otherwise disabled. Read the description of Wi-Fi scanning. Bluetooth and Wi-Fi scanning toggles are standard Android toggles enabled by default on the stock OS. They are not specific to our network location implementation but rather impact any apps granted the required permission to do scans.

                                            Murcielago

                                            Murcielago support for blocking callers who are not in the contacts

                                            I tried to do this two days ago and could find no way to block a spam caller. I sure as heck didn't want to add the jerk to my contacts list.

                                                  SteveC On which OS release? There's an "Add a number" UI in the Phone app within the Blocked numbers menu.

                                                      GrapheneOS Build number 2025031400 (i.e. later than this).

                                                      So I have to go to a special "blocked numbers" area to add a number?

                                                      Why cant I just do that from the calls log, when I am looking at the number of the loser? There ought to be a "block number" option there.

                                                          SteveC That's the standard UI for it. We could add another UI later when we heavily fork AOSP Dialer into a standalone app, which we haven't done yet, and other apps are being done first.