GrapheneOS It doesn't bypass the VPN. That only applies to connectivity checks in order for them to work, the standard Android NTP functionality we don't use in order for it to work reliably and fix time issues impacting VPN connections and Wi-Fi calling/texting due to it using an IPSec tunnel which can't be routed through every VPN.

In that case I suggest to add a clear warning to the screen where network location provider can be enabled that it is not safe to use it together with a VPN, as enabling it will nullify any anonymity the VPN otherwise would give. As already evident from this thread here, people do not realize it will deanonymize them.

Even better, force disable network location provider if a VPN is set. Since @vincente213 answer makes me uncertain people would even listen to a warning. And it is easy to forget one have network location provider enabled, if one add on the VPN at a later point in time.

Does the network location provider use the owner VPN, or the current profile VPN? Is network location provider enabled per profile, or globally for the device?

    Could someone kindly explain like I'm five, how using a VPN along with the network location provider will potentially hurt my privacy?

      fid02 Could someone kindly explain like I'm five, how using a VPN along with the network location provider will potentially hurt my privacy?

      You write a post exposing corruption in your government, posting it anonymously to social media. Your device also gathers a list of nearby Wifi hotspot, to ask for current location. Both of these are sent encrypted to your VPN, and pops out at the other end of the VPN. The adversary at the other end of the VPN now observes an anonymous message exposing corruption, and a list of nearby Wifi hotspots and thus pretty accurate location of that poster.

      Whereas if the request for current location didn't go over the VPN, but out directly, the adversary at the other end of the VPN would only see the anonymous message exposing corruption, and wouldn't know where in the country that poster is located.

          redfoxjumper does it not use https?

          Yes. Both for the posting to the social media, and for the network location lookup. But in the VPN model we assume an adversary can obtain information anyway. If HTTPS would prevent this, we wouldn't even need to use VPNs.

          Think if both the social media and Apple location server would comply with requests of server logs or active logging from the corrupt government, or even GrapheneOS location proxy would be forced to. This is what VPNs are supposed to protect against, by masking your actual location in the first place.

              ryrona The adversary at the other end of the VPN now observes an anonymous message exposing corruption, and a list of nearby Wifi hotspots and thus pretty accurate location of that poster.

              I'm sorry, I don't get it. How is the adversary controlling the VPN? Are you assuming that the adversary is in control of the VPN's servers, or that the adversary has inserted code into the VPN app that is installed on users' devices? If the former, how would the adversary see a list of nearby WiFi hotspots when it's a proxy gathering the list of hotspots (I assume, over HTTPS)? If the latter, then yes I understand.

                  ryrona one of the purposes of a VPN is to mix your traffic with that of other people. Without this factor, the government can just use data from your ISP for connections to the VPN and data from the social media company for connections from the VPN to correlate what traffic is yours.

                  How could they correlate 2 requests outgoing from the same VPN as coming from the same individual user, while at the same time, being unable to correlate one outgoing request as coming from one user?

                  Even if you don't use network location, the government already knows that you used the VPN and a VPN user made the social media post. Using network location only tells them that you are a user of the VPN, which they already know

                      vincente213 i am not sure if i understand you correctly, but as far as i am aware, is it possible to deduce your identity when you are just using a vpn. (by surveying the isp traffic and outgoing vpn server traffic)

                      I think it would be probably easier to somehow get your identity by matching the ip of a social media post to the ip of a location service request.

                      I think he means it is a unecessary risk to have your "anonym" ip and location having a correlation, since this is not necessary/ has only drawbacks

                          dhhdjbd I agree that it is possible to connect your identity to your VPN activity. My point was more that the only way to connect your two VPN connections is to connect each of them to you seperately, because there is nothing common between the requests besides you. But, if they are able to connect the social media post to you, they don't even need to bother with connecting the network location request to you because they already know you made the post. In this situation, using network location doesn't leak any information about you that wasn't already known.

                          However, by disconnecting the network location service from my VPN, Apple and my ISP, and by extension, the government, will easily be able to deduce that I (my real identity) use GrapheneOS (since I don't have an iPhone and am connecting to Apple's location servers). It would attract special attention on me, which I would like to avoid.

                              redfoxjumper It uses HTTPS and we've also added basic TLS key pinning of the CA roots and our per-service backup keys for the GrapheneOS proxy option similar to our other apps.

                                fid02 How is the adversary controlling the VPN?

                                I didn't say they control the VPN. I said they are after the VPN.

                                You -> Your ISP -> Your VPN provider -> Websites / Adversary

                                vincente213 one of the purposes of a VPN is to mix your traffic with that of other people.

                                No. That is not part of the security expectations of a VPN. A VPN cannot and won't even try to guarantee there are other users connected to the same VPN node as you are, at the same time as you are. On top of that, little analysis have been done or even possible to do on what additional privacy or anonymity you would get from more users using the same VPN node as you during the same time. Probably far less additional anonymity than most would expect, because uptime and usage pattern and device and so on might still be correlatable.

                                In the VPN model we only expect one thing, and that is that the requests to websites and services will look like they are coming from the VPN node IP address rather than your own real IP address. That is, your location is masked. That is the only guarantee we have from VPN, and the only expectation we can have. If you then send your real location to the remote services, you will deanonymize yourself.

                                vincente213 Without this factor, the government can just use data from your ISP for connections to the VPN and data from the social media company for connections from the VPN to correlate what traffic is yours.

                                They can always do this. This is called a traffic confirmation attack. One type is called tagging attack. Not even Tor can protect against this, and the Tor project have published a lot of information about these kinds of attacks and why they are hard to protect against. If the adversary already suspect it is you that is responsible for some activity, they can trivially confirm it actually is you. Neither VPNs nor Tor try to protect against this, it simply isn't feasible. Instead, they try to protect you when the adversary has no idea who is responsible for the activity, and try to backtrack through the network to find out who.

                                vincente213 How could they correlate 2 requests outgoing from the same VPN as coming from the same individual user

                                You might be the only one using GrapheneOS that is using that specific VPN node at that specific point in time, for example. Or one of only 10, which already that gives a very small anonymity set. That would be pretty revealing. Phones makes this especially obvious, as they turn off network when screen is off, and start sending traffic from many apps at once when screen is turned on again, as a battery saving function.

                                vincente213 Using network location only tells them that you are a user of the VPN, which they already know

                                No! It also tells them exactly where you are!

                                dhhdjbd he

                                I am a woman. Please do not assume people's gender.

                                dhhdjbd means it is a unecessary risk to have your "anonym" ip and location having a correlation, since this is not necessary/ has only drawbacks

                                It is an understatement, but yes. All anonymity guarantees made on VPNs assume you aren't sending your true identity or location through the VPN. If you do, it gets very hard to prove you still have any anonymity at all, even in specific use cases, because there are still all kinds of correlations, and in general, you don't have any anonymity anymore at that point. The general case being, no HTTPS used.

                                Better use VPNs as they are intended to be used. And that means, do not send your true identity or true location over the VPN.

                                vincente213 My point was more that the only way to connect your two VPN connections is to connect each of them to you seperately, because there is nothing common between the requests besides you.

                                There are plenty of things in common with them.

                                vincente213 However, by disconnecting the network location service from my VPN, Apple and my ISP, and by extension, the government, will easily be able to deduce that I (my real identity) use GrapheneOS (since I don't have an iPhone and am connecting to Apple's location servers). It would attract special attention on me, which I would like to avoid.

                                Hiding from your ISP is a valid use-case, but not the one I am considering.

                                My intention with the post was only to alert the GrapheneOS developers of this anonymity concern, so they can make a good decision about what to do about it, preferably before the new release reaching stable, but at the very least soon after. Many people specifically need their activity over VPN to not be correlated with their real identity or real location. Maybe this is not the case for you, and you worry more about your ISP knowing what OS you use. But believe me, it is very much a concern for activists, which is the group I belong to. So I do hope the GrapheneOS team takes these anonymity concerns seriously.

                                                    This new network location client is indeed impressive!

                                                    ryrona Network location isn't enabled by default and it works in the same way as other system services by sending the traffic through the Owner user VPN. SUPL works the same way on Tensor Pixels. Not sending traffic through the VPN is unexpected. Connectivity checks are a very special case which works that way and are documented as such. It's already what users expect for traffic from a profile to go through the VPN for a profile and OS services not tied to a particular profile to go through the Owner user VPN. Location services run globally as part of Owner, not per-user, which is easy to figure out from the settings being global and the state of it clearly being globally shared, similar to how there's no avoiding the fact that Wi-Fi, etc. is shared underneath profiles. In theory, there could be separate network location per user which runs in parallel at the same time but it would be inefficient and strange for it to work that way.

                                                    We've made it clear that we're working on support for offline network location via downloaded databases and that we don't want to enable a server-based approach by default.

                                                    Wi-Fi calling/texting requires an IPSec tunnel which is not routed through the VPN but it would be good if there was a way to do it. It's unfortunate VoWiFi is implemented that way, but it's the way was designed and we can't change that, we can only work within the constraints of what it requires.

                                                    On Snapdragon Pixels, SUPL worked differently since Qualcomm implemented it in the baseband based on how the OS configured it. Qualcomm's SUPL connects to supl.grapheneos.org or the standard SUPL server (depends on carrier, but usually supl.google.com) via the cellular radio TCP/IP stack directly. We want to make our own SUPL implementation based on our network location database. It could even be coerced to work offline eventually too.

                                                        GrapheneOS But you do agree enabling network location provider does break the anonymity that the owner VPN would offer? You also do agree your average user cannot possibly realize this would happen, as it requires deep understanding of how VPNs and network location queries work?

                                                        You and me would realize this, but not the average user GrapheneOS is trying to protect.

                                                        Cannot you just add a short warning to the option enabling network location provider, like, "It is recommended to leave this off if you use VPNs for anonymity". It is a small change, and absolutely enough to discourage people with serious threat scenarios from enabling it, while not discouraging anyone else from doing it. Very easy to understand, it is a clear and concise warning.

                                                            Question: if we block phone numbers that are not in our contacts, do we still receive a notification of a missed conversation with that number?

                                                            ryrona

                                                            But you do agree enabling network location provider does break the anonymity that the owner VPN would offer? You also do agree your average user cannot possibly realize this would happen, as it requires deep understanding of how VPNs and network location queries work?

                                                            It does not break the anonymity of the VPN. When using the recommended proxy mode, it sends location data (nearby Wi-Fi networks and also cell towers when we add it) through an HTTPS connection with pinned TLS keys (Let's Encrypt roots and our backup leaf keys) to a GrapheneOS server which then sends them to Apple. That's why it's not enabled by default. This does not break the anonymity of a VPN. 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. 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.

                                                            Cannot you just add a short warning to the option enabling network location provider, like, "It is recommended to leave this off if you use VPNs for anonymity". It is a small change, and absolutely enough to discourage people with serious threat scenarios from enabling it, while not discouraging anyone else from doing it. Very easy to understand, it is a clear and concise warning.

                                                            We're clear that it sends location revealing data to a service. It's similar to sending location data to other services such as using Google Maps, Tinder, etc. although most people would trust sending that to a GrapheneOS service with a reasonable TLS key pinning setup much more than sending it elsewhere. That's there in the explanation.

                                                                GrapheneOS I don't understand it. Can you explain it? Like in the easiest words possible? What is it you are working on what is it's purpose and stuff?

                                                                    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.