Stop Calling Them VPNs!

This is a bit of a follow-up from a previous post on public (hotel) WiFi, and something of a pet peeve for myself that keeps getting on my nerves and I need to get off my chest: I’m tired of the marketing of various network aggregators and tunnels as “VPNs.”

I’m conscious that it’s a bit of a “Granpa Simpsons Yell At Cloud” moment — but back in my days, the name Virtual Private Network referred to the idea of creating a private network on top of a public network — nothing to do with browsing privately, rather a way to push the trust down the chain, and let your home computer / laptop / phone connect to (mostly) your employer’s intranet without having to expose the various services on the Internet. Or alternative to allow multiple sites to share a common Intranet address space, even though they have independent Internet connections.

In those configurations, the important part is that all of the nodes connected to the VPN server were almost all trusted by the organization owning the VPN server as if they were connected to the very same corporate network in the office.

Indeed back when these concepts were new, the fact that you would be able to exit to the Internet via a VPN connection was not a given, because of the limited bandwidth between them. Indeed, you would be more likely to have a split-network configuration, where only the traffic meant to go the Intranet would be sent through the VPN connection — this turned out to be generally a bad idea, so you rarely ever see that happening nowadays.

Services like NordVPN, ProtonVPN, ExpressVPN, and so on — are not VPNs in that sense at all! The closet you get to that is NordVPN’s “Mesh” offering, which is basically yet another branded implementation of Wireguard to my understanding — and if you need that, I would rather recommend Tailscale (mostly because I know the folks over there and they’re trustworthy, while NordVPN leaves me… bad impressions.

All of these services are effectively traffic aggregators, or tunnels — just like TunnelBear, which at least makes it very obvious in their name and marketing copy, though they also insist on you gaining some type of browsing privacy by using their service. I’m almost going to praise Apple for their branding, since they call it iCloud Private Relay. The “Private” part is in my opinion misleading – it’s not like they assign you our own relay machine or IP on their iCloud service – but at least they make it clear that it is a Relay service, not a VPN.

So why are they called VPNs? I guess the answer is that they show up as if they were VPNs to many of the operating systems they support. They use protocols such as OpenVPN, or maybe nowadays Wireguard, and before that they used L2TP or IPsec. All of those protocols have classically been used for VPNs, and these traffic aggregators just happen to use the same, because it is the to ask an operating system to send all of the traffic to a different connection than the “simple” base WiFi, Ethernet, or mobile connection.

But I guess the fact that VPN had “Private” in the name meant the marketing folks realized they could entice more users into signing up for their services by suggesting they would somehow be able to improve their privacy posture by using their service. And the thing is, the snakeoil smell is strong with these, but there are situations where they actually provide a level of utility, to the point I actually have paid for ExpressVPN at least twice, and have TunnelBear installed (but inactive) on many of my devices. But “privacy” is not the utility I concede them to have.

Part of the problem is to establish a threat model: whenever I criticized the overuse of these tunneling solution, the first threat model that gets proposed is US-focused (no surprise there), particularly with the most recent authoritarian turns of some States. “What if the Government finds out a person went to X website?” — which, okay fair given the horrible state of affairs of the USA I can guess people are afraid of, but sounds relatively unlikely?

I accept that there’s a difference in effort between a US court subpoenaing a US-based ISP (particularly the more local entities that may even be easy to drag in from within a single State) compared to an oversea tunnel provider, but if they’re out to dig evidence to establish a crime they already assume a person committed, there’s likely an easier chance to get the data from the computers directly. Particularly so because, in the year 2024 (but also, for many years before that), an ISP cannot actually know what you searched, as all of the major search engines (as well as the vast majority of websites) use encrypted HTTPS connections, so that search terms (as well as usernames, passwords, and the content of your messages in webmails and various social network) are not actually transiting in plain text through the ISP.

Indeed, the same is true for ISPs, tunnel providers, and public WiFi operators (which from now on I’m going to refer to as “connectivity provider”.) None of them will be able to tell what you search within a website, or even what exact pages within that website you visited — as long as the website has been following the recommendations basically any field expert has been giving in the past 10 years at least!

But what about “which websites have you been visiting?” Well, that’s a more complicated question. As I wrote many years back, DNS queries used to always leak the name of websites you visited: even when the HTTPS connection was encrypted, so that nobody but you and the counterpart would be able to tell exactly what page you requested, and what the page contained, querying for the hostname would be leaking whether you were visiting Google, Instagram, a specific Mastodon instance, or your healthcare provider.

I used the past above, because since I wrote the Siphoning post, like I said in the Hotel WiFi post, things have been improving. DNS-over-HTTPS (DoH) is rapidly being deployed in more and more places, so that your DNS queries can no longer give away which website you resolved. DNS-over-HTTPS is implemented in Windows 11, systemd-resolved, as well as Chrome and Firefox, at the very least. I do not know what the state deployment is in the Apple ecosystem, and I don’t know if there’s any way to leverage it for those CompCon that refuse to use resolved.

The only thing that your connectivity provider can see, is which IP addresses you connect to – and depending on what the website you’re vising is doing, that might be damning enough indeed. If you’re reading this directly on my blog, your connectivity provider may not be able to tell you went to my blog (as long as you’re using DoH), but would be able to tell you interacted with one of my websites, because the IP addresses have a reverse resolution of ortisei.flameeyes.com.

Can we do better? Probably. Reverse resolution of IP addresses is one of those geeks’ things: it’s cool to be able to claim you own a certain address, but the reality is that it can cause you more headaches than it is worth. In many cases, the only real use for reverse resolution is to be found in outbound requests, so IP addresses serving website could be left without a reverse resolution, not to make it easy on someone reading through traffic logs to figure out which website the traffic source is visiting. But the reality is that unless the websites “hide in the crowd”, there is little chance for that to work — even if you didn’t know what the reverse resolution of my blog’s IP address is, you could get it through the HTTPS certificate it provides when hitting the bare IP address. But we’re straying further away from tunnel providers with this line of thoughts.

So assuming that the threat model is that someone is able to get your ISP to hand them your traffic data, what can the ISP see? Possibly your DNS queries (if you’re not using DoH), possibly the reverse DNS of the websites you visited, and certainly the IP addresses of the websites you visited. If you were to use a tunnel, what your ISP would see should be just you connecting to the VPN (though there’s always a risk of leakage if you don’t pay paranoid attention to it), but on the other hand, all of that metadata the ISP could have seen, becomes visible to the tunnel provider.

Which is why you need to put as much trust in your tunnel provider as you do in your ISP, if you’re a person who is at risk to be targeted by governments, institutions, or particularly pernicious actors. Many of the connectivity providers will make blanket statements of not keeping logs, but even those can change their mind. And many of those don’t even make such blanket statement, they just say they cannot see your traffic — which is possibly true, they can only see the metadata of your traffic, just like your ISP!

Actually, I would venture you should put more trust in your tunnel provider than your ISP if you use it constantly. Particularly if you believed the line that suggested using it to protect your privacy when using public-space WiFi. With the exception of the problems I already wrote about in the previous post about Apple’s sharing of device names and similar, it’s quite unlikely that a cafe ISP could be able single out your particular traffic out of many, even if you’r e a regular that comes every day. Most devices don’t advertise their name on public networks (though I admit I haven’t tried tabulating which one does what) and, to actually preserve privacy, most operating systems rotate the generated MAC address they proffer to public WiFi networks every day. But if you’re using a tunnel, your provider knows exactly which user generated the traffic metadata, no matter from where you used it!

I did say above that sometimes the right way to solve for privacy is to hide in the crowd — that was the original principle behind Panopticlick after all. But do these tunnel providers work as a crowd? While I have not seen any numbers, I would take a guess that the only real crowd that can hide you in there is Apple’s. And while, if you need privacy over most other characteristics, this can be a positive, it also comes with some disadvantages. If you are a tunnel user, and you keep finding yourself fighting uphill battles with captchas on Google, or errors on TicketMaster, and so on, the answer is that all of these services rely on a connection’s reputation — and when you’re using a tunnel, you’re trading on the reputation of the crowd.

This is something I have written about at length, in the context of my fight against blog comment spam. Making yourself invisible for privacy reasons has downsides, which start with the inconvenience of a captcha, and may end with being unable to rely on the beaten path to securing the access to your services. If your terminating connection keep bouncing around the world every hour or so, a service might take you for a compromised account, and make your life much harder to restore service, without the intention of discriminating against tunnel users.

To close up, I did say that tunnel providers have their own utility — and that I actually keep TunnelBear at hand. I have done this over the years for different reasons. For instance, for a while, I couldn’t buy the FreeStyle Libre in Ireland, so I used to order it to a Northern Irish re-shipping company; a few months in, Abbott restricted access to their website to British IP addresses, so I used TunnelBear to make the orders.

Some of the tunnel providers have made no mystery that the primary use cases for their customers is less about privacy and more about “piracy” — as in, defeating geographical restrictions on content, watching Netflix from different countries, or from your home country while on vacation. While I definitely empathise, the fact that they can blatantly state in their podcast Ads that they exist to break the terms of service of another company has always made me extremely uncomfortable: if that’s the regard they have for the agreements between users and other companies, what’s the regard they have for the agreement between their users and themselves? Are they going to suggest they don’t collect data, and then surreptitiously do it anyway?

More recently, I got to use an exit node on Tailscale more often, rather than Tunnerlbear: turns out that the one country I do need to “cloak” myself egressing from is my own. I do want to keep track of London’s news rather than the world’s, so when I’m traveling I read the BBC through my own home connection, through Tailscale — after all, I do pay my TV license, so I don’t care for either the ads or the wider world news. And my GP’s systems don’t work from an abroad connection, which is silly and all, but I guess immigrants are not their target audience — nor are people who travel.

So in short, I’m not here to convince you to drop off your tunnel providers, because I don’t know your personal circumstances and what is right for you. But I am hear to remind you that these providers are not known for having their users’ best interest in mind, and that they tend to forget very quickly about the snakeoil promises they made.

I am pleading you to stop calling them VPNs though — because they are most definitely not that. The whole “Private” part they’re appropriating for marketing purposes wasn’t ever about privacy in the first place.