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.

                        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.