We’ve all received the advice: “if you want to improve your privacy, get a VPN.” We disagree, but until today we don’t think anyone has explained why that isn’t particularly good advice. Below we explore why VPNs aren’t what users need, and we discuss what better options exist today. To explain this, we dig into the architectural choices privacy services can make, and explore which choices lead to better guarantees for users.
TL;DR: Multi-Party Relays (MPR) provide privacy in the architecture itself. MPRs are the better, practical alternatives to VPNs. Only now, in 2022, are there fast MPR services that cover all mobile users: INVISV Relay (Android) and Apple’s iCloud Private Relay (iOS).
First, let’s look at VPNs, what they are, and why they aren’t what you want for privacy.
VPNs: the Good, the Bad, and the Ugly
VPNs can be useful in narrow contexts, such as corporate VPNs used to create on-prem-like network environments. They can also help users get around country-level firewalls and censorship. However, they’re not what you want for privacy.
The simplest thing that’s leaked on the Internet, regardless of whether you’re using mobile data or WiFi, is your network identifier: your IP (Internet Protocol) address. Your IP address tells any device (computer, phone, etc.) anywhere in the world where you are on the network and can be used to send you traffic; and, of course, it’s on every packet your device sends out, identifying where that packet came from and where it is headed.
But one thing about networks is perhaps unique in the context of privacy: you must rely upon others to carry your data for you, and that means they can see and correlate your Internet traffic. This is big business: some companies boast of the breadth of Internet traffic they can see – that they can see over 3/4 of the Internet’s IP addresses – even across VPNs.
For the last couple of decades, we’ve known that it’s not good to leak your IP address to every network you traverse and server you contact. Not only can they manipulate the data and its routing (as occurs during route hijacking), but they can collect and correlate the traffic they see from you and others. As shown in the figure above, any network along the path between you and your destination can see both your IP address and the server you are communicating with – obviously a less than ideal situation. But the common solution has long been to simply put a third-party in the middle: a server or service that is trusted with all your traffic, to protect you from the network itself. Security gateways and firewalls are examples of these, but the most common one in this context is well known: VPNs.
A VPN is a service you trust to protect you from intermediate networks, and that requires that you put all of your network traffic in their hands – you send them your packets and they pass that traffic along to the destination servers. As shown in this diagram, they see both ends of a network connection – you (the source) and some site on the Internet (the destination). In cases where your access to large parts of the Internet is actively blocked, as in some countries, a VPN can be an essential lifeline to the public, open Internet. But even then, VPNs, security gateways, or similar technologies require putting more information in the hands of a third party than you do even when you use no such service. VPNs go through only one VPN provider, and therefore have no architectural protection separating you and your traffic. Also, almost all VPNs operate at a packet level, meaning that packet level correlations, depending upon the protocol, are possible as the raw packets from you go end to end via the VPN to the destination server.
VPN services often focus on everything other than the architecture. They talk about various promises and policies, the country their headquarters is located in (not their servers, which are usually all over the world and subject to local laws), and about how their processing is done in RAM (which is how all network packet routing and processing is done – otherwise it’d be painfully slow). While such analysis can provide some comfort for users, it does not fundamentally change the fact that VPN companies see every network connection every user of theirs makes: the user’s IP and the destination server on the Internet. It’s the architecture that matters, and that is the problem.
What does a VPN see of your Internet traffic?
Let’s look at what VPNs can see. Since they have your IP address they can easily distinguish between users, and track every site that they visit, as shown in this figure. Alice, Bob, and Carol’s traffic is easily trackable over time.
To further illustrate, we ran a small experiment that can be easily replicated by anyone. We configured a wireguard VPN server (and the same would be true with any standard VPN server software). We configured a wireguard client on an Android phone, with all phone traffic set to go through the VPN server. On the VPN server we used tcpdump, the standard tool to see what network packets are visible at the VPN server. We then analyzed what network traffic tcpdump saw while we browsed on the phone. In the video, we show what the VPN server sees – as we visit a number of websites using multiple browsers, we show how the number of unique Internet server IPs that can be linked to that particular phone client rapidly goes up (since every connection made by the client through the VPN can be linked to it by the VPN – it sees everything after all).
A Better Way: Multi-Party Relays (MPR)
A better architecture means not having user-linkable data in the first place. We believe the only practical solution to this problem is to change the architecture such that your traffic is decoupled from your network identity. That means no more need to trust all the arguments VPNs make.
Fortunately, there’s an alternative design, dating back to Chaum’s foundational research from the 1980s. Instead of trusting just a single hop, it’s better to divide information and knowledge across multiple parties – that means servers run by distinct companies/organizations – where no one party can see both the user’s identity and the user’s traffic. Tor is a service that embodies this idea, though users often want better performance than Tor provides.
Until recently users had no options to get the best of both worlds – Multi-Party Relay (MPR) service that’s secure, fast, and just works. But now, in 2022, there are two options: INVISV Relay (Android) and Apple’s iCloud Private Relay (iOS). (And INVISV Relay is to our knowledge the only high-performance MPR service that’s general purpose – meaning it works with nearly all unmodified apps on your Android device.)
What do MPRs see? Given that the information is split across multiple organizations, no one party has access to both the client identity and their browsing behavior. INVISV only sees client IP addresses, but all traffic is encrypted and the destinations are hidden from us. Here, the IP addresses for three users (let’s call them Alice, Bob, and Carol for convenience, though the server doesn’t actually know who they are) are seen connecting to the Internet, but INVISV servers only see that their traffic is headed to Fastly, our infrastructure partner.
Fastly, our partner network for INVISV Relay, only sees the destination servers, but cannot tell which INVISV Relay user is causing the traffic. Alice, Bob, and Carol all look like INVISV servers from Fastly’s perspective.
The Decoupling Principle
In previous blog posts, we’ve talked about something we call the Decoupling Principle: the principle that to provide practical network privacy, you need to decouple who you are from what you use, decouple network identity (who the network thinks you are) from user data (the actual private data you are sending or receiving), and decouple who knows what among this sensitive information (ensuring no one company sees everything). This has been known to privacy and security folks for a long time.
The Internet is maybe the largest and now most essential system humanity has ever built, but privacy and security weren’t designed into it from the start. Everything we’ve done over the years to improve Internet privacy and security has been despite, not thanks to, the Internet’s inherent design.
INVISV Relay: Design
INVISV Relay leverages Chaum’s classic idea: INVISV’s servers learn nothing sensitive about a user’s identity and traffic when using INVISV Relay. We apply the Decoupling Principle: your network identity (your IP address) is decoupled from your user data (your Internet requests, such as web browsing), and decoupled across multiple parties (INVISV, Fastly, and the destination service you’re accessing). When you connect to the Internet using INVISV Relay, your Internet provider just sees a fully encrypted stream of packets headed to our INVISV server, no matter where your data is actually going. All that our INVISV server sees is that some IP address (you) is sending packets to the server, but nothing more – our servers only know that Fastly, the next hop/party, is the destination of all your packets, and only Fastly can decrypt that layer of TLS encryption. Your packets’ source IP addresses are no longer visible when we route your packets to Fastly’s servers – Fastly’s servers think the packets are coming from INVISV servers, not from some particular user, using the IETF MASQUE specification. So Fastly learns only that there is some INVISV request to be routed to some IP on the Internet, and end-to-end TLS encryption protects the traffic from your device all the way to the destination server.
IETF MASQUE is a general-purpose way to use TLS-encrypted HTTPS connections to make proxied connections to servers on the Internet. TLS is already used nearly everywhere on the Web and is widely vetted and supported, so we benefit from building on top of it. However a single tunnel is not enough – it’s important to ensure end-to-end encryption for your traffic, which means there are multiple nested levels of TLS encryption in use and in doing this we ensure that your browser or app has an end-to-end encrypted connection from your phone to a destination server or service, all tunneled in yet more TLS encryption from your device to INVISV to Fastly.
INVISV Relay’s design is similar to Apple’s iCloud Private Relay, which is built upon the same IETF MASQUE specification and is available on Apple devices for use with Apple apps. Tor has a similar design in that it nests encrypted streams across multiple network hops to gain Internet privacy, but as a volunteer service it runs into significant performance and operational difficulties.
INVISV Relay has one other significant upside: it is designed to work with all the apps on your Android device, not a select few. For technical details on how we made INVISV Relay work, see this post that dives into the guts of our implementation of Relay.
What About DNS?
DNS traffic is another common way to track someone’s Internet habits, as DNS servers can observe the network identifier (IP address) along with the name of every server you want to connect to. Fortunately, we have experience in making DNS more private since a member of the INVISV team (Paul) created Oblivious DNS, a protocol that has been adopted as Oblivious DNS over HTTPS (ODoH) by Apple for Private Relay. With INVISV Relay, DNS traffic is encrypted over multiple hops and sent via Relay, as in Oblivious DNS – providing it with the same decoupled privacy benefits other traffic gets via Relay.
What You Can Do: Get an MPR Service
There are two commercial MPR services that you can use right now – INVISV Relay for Android and Apple’s iCloud Private Relay (for Apple devices) – and one major free option (Tor) available today. It’s just a couple of clicks to subscribe and enable the service.