Daniel sent us this one — and it's essentially a question about what the encryption revolution actually left behind. We did that whole episode on SSL certificates, and the upshot was that basically everything on the web is encrypted now. Browsers throw warnings if you even glance at a plain HTTP site. But then he points out that we've also talked about VPNs, and the standard advice is still to use one on untrusted networks — coffee shop Wi-Fi, airport lounges, hotel lobbies. The rationale is always man-in-the-middle attacks or packet sniffing. And here's the question: if we've got end-to-end encryption everywhere, isn't even the local network traffic safe? And if you're not using an encrypted service, is the traffic from your device to the router just flying around in the clear? There's a lot to unpack here.
There is, and the first thing I want to do is sharpen what "end-to-end encryption everywhere" actually means, because that phrase is doing a lot of heavy lifting that it might not deserve. The web is overwhelmingly encrypted now — we're north of ninety-five percent of page loads over HTTPS, and that's genuinely one of the great infrastructure wins of the last decade. Let's Encrypt, the whole certificate transparency ecosystem, browser vendors willing to be the bad cop — it worked.
The glockenspiel of internet security finally got tuned.
I don't even know what that means, but I'm going to accept it. Here's the thing though: HTTPS encrypts the connection between your browser and the web server. That's it. It does not encrypt everything your device sends over the local network. Your device is a chatterbox. It's constantly broadcasting information before you even open a browser tab.
The encryption story is more like — the postcards inside the envelope are sealed, but the envelope itself has your name and address on it, and also your device is shouting other things into the room entirely.
And the shouting is way louder than most people realize. When your laptop connects to a Wi-Fi network, before any HTTPS session even begins, it's doing a whole negotiation dance that's completely visible to anyone listening. DHCP requests — your device saying "hello, I need an IP address" — those are unencrypted. DNS queries, unless you've specifically configured DNS over HTTPS or DNS over TLS, are sent in plaintext. So even if the actual web page you load is encrypted, the fact that you visited "myweirdprompts dot com" is broadcast to everyone on the network.
Which is the digital equivalent of whispering your secrets but announcing your itinerary over a megaphone.
The itinerary itself can be incredibly revealing. The EFF laid this out a few years back — they pointed out that HTTPS hides the content of what you're reading, but the domain names you visit, the IP addresses you connect to, the timing and size of your data flows — all of that metadata is still visible. If you're on an untrusted network and you visit a site about a specific medical condition, the content of the page is encrypted, but the fact that you visited the Mayo Clinic page for that condition is not.
The VPN conversation isn't made obsolete by HTTPS. It's just that what the VPN is protecting has shifted.
Right, and this is where most of the popular coverage gets it wrong. The narrative a few years back was "HTTPS everywhere means VPNs are dead." That was always too simple. Troy Hunt — he runs Have I Been Pwned — wrote about this exact question. His take was that HTTPS solved the content confidentiality problem for web browsing, but it didn't solve the metadata problem, and it didn't solve the problem for all the other protocols your device uses that aren't web browsing.
Let's get into those other protocols. What else is my laptop doing while I'm innocently checking my email at a coffee shop?
Oh, this is where it gets fun. Your email client might be using IMAP or POP3 to fetch mail. Unless you've explicitly configured TLS for those — and many clients do by default now, but not all — your username and password are transmitted in a way that's trivially sniffable. Even with TLS, the server hostname is visible in the SNI handshake. Your device might be checking for software updates — many updaters use HTTPS now, but some legacy ones still fetch manifest files over HTTP. Your phone is probably running a dozen background apps making API calls, and while most of those are encrypted, the DNS queries revealing which services you use are not.
SNI — that's Server Name Indication. Explain that, because it's one of those details that sounds like technical arcana but actually matters for this conversation.
When your browser connects to a server that hosts multiple websites — which is basically every major site behind CDNs and shared infrastructure — it needs to tell the server which site it wants before the encrypted connection is established. That's the SNI field. It's sent in plaintext during the TLS handshake. So an observer on the local network sees, "this device is connecting to Cloudflare's IP address, and it's requesting the domain name 'plannedparenthood dot org' or 'nra dot org' or whatever." The content of the visit is encrypted. The fact of the visit is broadcast.
It's like walking into a building with tinted windows. Nobody sees what you do inside, but they absolutely see which building you walked into.
How long you stayed, and how many rooms you visited, and what time you arrived. The traffic analysis side of this is sophisticated. Researchers have shown that you can identify specific YouTube videos someone is watching just from the pattern of encrypted data bursts, because different videos have different bitrate profiles. You can identify which pages someone visits on a website based on the size and sequence of the objects loaded.
The musical equivalent of beige wallpaper — the traffic patterns are distinctive even when the content is hidden.
I'm going to start keeping a list of your analogies. But yes, exactly. And this brings us back to the core question: what does a VPN actually protect in a world of ubiquitous HTTPS? It protects the metadata. When you use a VPN, all of your traffic — DNS queries, SNI fields, connection timing, destination IP addresses — is tunneled through an encrypted connection to the VPN server. The local network observer sees one thing: an encrypted tunnel between your device and the VPN provider. They don't see which sites you visit, which services you use, which apps are phoning home.
Of course, you've just shifted the trust from the local network to the VPN provider. Which is its own can of worms.
And we should talk about that. But let's first finish the local network threat model, because there's a specific part of the prompt that I want to address directly. The question asks: if you're not using an end-to-end encrypted service, is the traffic on the way to the router traveling unencrypted? The answer is yes, and it's not just a theoretical concern.
Give me the concrete scenario. I'm at a coffee shop. I fire up some random app on my phone that doesn't use encryption. What actually happens?
The radio waves carrying your data from your phone to the Wi-Fi access point are, by default, encrypted at the link layer if the network uses WPA2 or WPA3. But here's the crucial distinction: that encryption is between your device and the access point. It's not end-to-end. The access point decrypts the traffic and then forwards it onward. So if the access point itself is malicious — and this is the classic "evil twin" attack — or if the network operator is logging traffic, or if someone has compromised the router, your unencrypted application traffic is fully visible at the router level.
WPA2 is the lock on the door, but the person who owns the door has the key.
In a public Wi-Fi scenario, you don't know who owns the door. You don't know if the access point named "CoffeeShop_WiFi" is actually operated by the coffee shop or by the person sitting three tables over with a laptop running a hotspot with a deceptive name.
The person three tables over is always the most interesting character in these threat models.
They really are. And the evil twin attack is not exotic. The equipment to do it is a laptop with a Wi-Fi card and freely available software. You broadcast a network with the same name as the legitimate one, or a more enticing one — "CoffeeShop_Free_Fast" — and devices connect to you instead. From there, you can intercept everything. If the traffic is HTTPS, you can still see the metadata we talked about. If it's unencrypted HTTP, or an unencrypted email connection, or an FTP session, or a legacy chat protocol — you see everything. Usernames, passwords, session tokens, the full content.
There are still unencrypted services in the wild? In a world where browsers literally shame websites for not using HTTPS?
The browser ecosystem has largely solved this for web traffic, but the internet is much bigger than the web. IoT devices are notorious for this. Smart home gadgets, security cameras, baby monitors — many of them communicate over the local network without encryption because the manufacturer assumed they'd only ever be used on a trusted home network. But when you take your phone to a coffee shop, your phone might be running apps that communicate with those devices back home, or with cloud services, over protocols that aren't fully encrypted.
Like adopting a feral cat. You think you're just bringing one thing into the coffee shop, but it's connected to a whole ecosystem you didn't inspect.
Some of those connections are surprising. There was a security researcher a few years ago who found that a popular weather app was sending location data over unencrypted HTTP. A weather app. The kind of thing you'd never think twice about installing. On a local network, anyone running a packet sniffer could see exactly where that person was.
Let's map this out systematically, because the prompt is really asking for a threat model breakdown. We've got three layers. Layer one: link-layer encryption between device and access point. Layer two: transport-layer encryption for specific applications — that's your HTTPS, your TLS-wrapped email, your encrypted messaging. Layer three: network-layer encryption — that's the VPN tunnel. And each layer protects against different things, and the gaps between them are where the interesting problems live.
That's a really clean framework. Let's walk through it. Link-layer encryption — WPA2, WPA3 — protects against passive eavesdropping by someone who's not on the network. If you're just sitting in the parking lot with an antenna, you can't read the raw Wi-Fi frames. But as we said, it doesn't protect against the network operator or anyone who's authenticated to the same network. And on most public Wi-Fi networks, client isolation is not enabled, meaning devices on the network can see each other's traffic.
That's the setting that says "these devices can talk to the internet but not to each other." And it's usually off.
Usually off, because it breaks things people expect to work — AirDrop, network printing, file sharing. So you're on a network with thirty strangers, and your device can see their broadcast traffic and they can see yours. That's the environment we're operating in.
Layer two then. This is where HTTPS lives.
It's where the bulk of the protection actually happens in practice. If you're visiting a properly configured HTTPS site with a valid certificate, with HSTS enabled, the content of your communication is safe from everyone on that local network. They can't read what you're posting, they can't steal your session cookies, they can't inject malicious content into the page. This is a genuine, hard-won security property. The certificate authority system, for all its flaws, makes this work.
We've already identified what it doesn't protect. Metadata, DNS, SNI, traffic patterns.
There's another thing it doesn't protect against that's particularly relevant to the local network scenario: active attacks that happen before the HTTPS connection is established. The classic one is SSL stripping. An attacker on the local network intercepts your request to visit a website. You type "facebook dot com" into your browser. Your browser initially sends an HTTP request, because you didn't type "https colon slash slash." The attacker intercepts that request and maintains an HTTPS connection with Facebook on your behalf, but serves you the content over HTTP. You never see the lock icon, but you might not notice its absence.
HSTS is supposed to prevent this.
HSTS — HTTP Strict Transport Security — tells your browser "always use HTTPS for this domain, don't even try HTTP." Once your browser has visited a site with HSTS, it remembers that directive for a specified period. But the first time you visit a site, before that HSTS policy is cached, you're vulnerable. This is called the trust-on-first-use problem. And some sites don't implement HSTS at all. And even with HSTS preloading — where browsers ship with a list of domains that require HTTPS — the list isn't exhaustive.
There's a window of vulnerability that a local attacker can exploit, even in a world where the destination site is perfectly configured for HTTPS.
And the local network is the perfect place to exploit it, because the attacker is in the path between you and the internet. They can intercept and modify traffic in real time. This is the classic man-in-the-middle scenario that VPN advocates warn about, and it's not solved by HTTPS alone.
Which brings us to layer three — the VPN tunnel. And this is where I want to push back a little, because the VPN conversation often gets reduced to "use a VPN and you're safe," and that's not quite right either.
No, it's not. The VPN industry has done itself no favors with the marketing. The "military-grade encryption" nonsense, the scare tactics about hackers stealing your bank password at Starbucks — it's created a cartoon version of the threat model that doesn't match reality. But the underlying technical value is real, just more nuanced than the ads suggest.
What does the VPN actually do in this three-layer model? It wraps everything from layer two and layer three into a single encrypted tunnel. All your traffic, regardless of application, regardless of whether the application itself uses encryption, gets routed through the VPN server. The local attacker sees nothing but encrypted noise.
The DNS queries are handled by the VPN provider's DNS servers, so the local network doesn't even see those. The SNI handshake happens between the VPN server and the destination, not between your device and the destination directly. Your real IP address is hidden from the sites you visit. All of the metadata we talked about — which sites, when, how long, what patterns — is invisible to the local network.
Visible to the VPN provider.
You've moved the trust boundary. When you use a VPN, you are trusting the VPN provider with exactly the information you're hiding from the local network. Your browsing history, your DNS queries, your connection metadata. For some threat models, that's a good trade — your VPN provider is a known entity with a published privacy policy and a reputation to maintain, while the random coffee shop Wi-Fi is an unknown. But it's a trade, not a pure win.
Not all VPN providers are created equal. There are providers that log everything, providers that log nothing, providers that say they log nothing but their privacy policy has carve-outs, providers that have been caught lying about their logging practices.
The VPN trust decision is hard. You need to evaluate jurisdiction — where is the company incorporated, what are the data retention laws in that country, what are the intelligence-sharing agreements. You need to evaluate technical architecture — do they run their own DNS servers, do they own their physical infrastructure or rent it, have they undergone independent security audits. You need to evaluate business model — if the service is free, you are the product, and your browsing data is being monetized somehow.
The free VPN is the gas station sushi of internet security.
That's going on the list too. But yes, free VPNs have been caught injecting ads, tracking users, and in some cases literally selling user browsing data to analytics companies. There was a study a few years ago that found something like forty percent of free VPN apps on Android had some form of malware or tracking behavior. It's a minefield.
We've established that HTTPS protects content but not metadata on the local network. A VPN protects both content and metadata from the local network, but shifts the trust to the VPN provider. What about the scenario where you're not using an encrypted service at all? The prompt asks about that specifically — traffic on the way to the router.
That traffic is completely exposed to anyone on the local network. And I want to be precise about what "on the way to the router" means. Your device sends data as radio waves. Any device within range that's listening on that channel can capture those frames. If the Wi-Fi network uses WPA2, the frames are encrypted between your device and the access point, so a passive eavesdropper who hasn't authenticated to the network can't read them. But anyone who has the Wi-Fi password — which on a public network is everyone in the coffee shop — can potentially capture and decrypt that traffic.
That depends on whether the network uses per-device encryption keys.
WPA2-Personal, which is what almost all public Wi-Fi uses, uses a shared key. Everyone with the password derives the same encryption key. So if you have the password, you can decrypt everyone's traffic. WPA3 improves this with individualized data encryption, but adoption is still not universal. And even with WPA3, the access point itself decrypts the traffic. So the network operator — or anyone who's compromised the access point — sees everything.
The "on the way to the router" traffic is encrypted over the air if the network uses WPA, but it's decrypted at the router, and it's visible to anyone who can capture it on the local network segment after decryption. Which is basically anyone on the same network.
Let's talk about what unencrypted traffic actually looks like in practice. HTTP web traffic — if you somehow end up on an HTTP site, which is increasingly rare but not impossible — transmits everything in plaintext. The URL path, any form data you submit, any cookies. An attacker can see exactly what pages you're viewing and can steal your session cookies to impersonate you. Email protocols without TLS — IMAP on port one forty-three, POP3 on port one ten, SMTP on port twenty-five — transmit usernames and passwords in plaintext. FTP transmits everything including login credentials in plaintext. Telnet transmits every keystroke in plaintext.
There's a protocol I haven't thought about in a while.
You'd be surprised. It's still used in industrial control systems, in legacy enterprise environments, in embedded devices. And there are plenty of other protocols that don't encrypt by default — SNMP versions one and two send community strings, which are essentially passwords, in plaintext. LDAP without TLS sends directory queries in plaintext. And then there are all the custom protocols used by mobile apps and IoT devices, many of which were written without any security consideration at all.
The answer to the prompt's direct question — "is the traffic on the way to the router traveling unencrypted?" — is: it depends on what traffic, and it depends on the network, but there is definitely a category of traffic that is completely exposed, and there are categories of traffic that are partially exposed, and the Venn diagram of "things you'd rather strangers didn't see" and "things that are exposed" has a lot of overlap.
I want to add one more category that often gets overlooked: the local network itself has services running on it that your device might interact with automatically. When your device connects to a network, it might try to discover printers, file shares, media servers. These discovery protocols — mDNS, SSDP, NetBIOS — are unencrypted. They broadcast information about your device and its capabilities to everyone on the network. Your device is essentially introducing itself to the room before you've even done anything.
"Hello, I'm Corn's laptop. Here are the file shares I'm looking for. Here's my hostname, which contains my real name because I set this up at home and never changed it.
And that hostname thing is not a joke. I've seen network captures where devices broadcast hostnames like "Sarahs-MacBook-Pro" or "David-Work-Laptop." That's information leakage that happens before any application even opens.
Let's pull this together into something actionable. If I'm a listener who's followed the HTTPS-everywhere narrative and concluded that I don't need to worry about network security anymore, what am I getting wrong?
You're getting wrong that HTTPS is a complete solution. It's a spectacular solution for the specific problem of web content confidentiality, but your digital life is much broader than web browsing. Your device is constantly emitting signals — DNS queries, connection metadata, service discovery broadcasts, background app traffic — that HTTPS doesn't protect. On a trusted home network, this is probably fine. On an untrusted public network, it's a meaningful privacy exposure.
The VPN is the answer to that exposure, but it comes with its own trust decision.
The VPN encrypts everything from your device to the VPN server. The local network sees nothing but an opaque tunnel. This solves the local network threat model comprehensively. But you have to trust the VPN provider, and you have to choose one that's technically competent and legally constrained in ways that align with your threat model.
There's also an interesting middle ground that's emerged in the last few years. DNS over HTTPS, or DoH, which encrypts your DNS queries without routing all your traffic through a VPN.
DoH is a significant improvement for the specific problem of DNS privacy. With traditional DNS, every domain name you look up is visible to everyone on the local network and to your ISP. With DoH, those queries are encrypted and sent to a DNS resolver of your choice. The local network can't see which sites you're resolving. But — and this is a big but — the SNI field in the TLS handshake still reveals the domain name to anyone watching the connection itself. So DoH hides the DNS query, but not the subsequent connection.
It's like whispering the address to your taxi driver, but then the taxi has the destination written on the side in large letters.
Which is why Encrypted Client Hello — ECH — is the next piece of the puzzle. ECH encrypts the SNI field, so the entire TLS handshake is private. Between DoH and ECH, you get something that looks a lot like VPN-level privacy for web browsing, without the VPN. But ECH is still rolling out, and it only applies to TLS connections. It doesn't protect your non-web traffic, your background app chatter, your service discovery broadcasts.
We're in this transitional period where the pieces are falling into place for a world where VPNs might be less necessary for the average user, but we're not there yet.
Even when we get there, VPNs will still have use cases. Geo-spoofing, bypassing censorship, protecting traffic from your ISP — those are problems that DoH and ECH don't solve. The VPN is a more comprehensive tool. The question is whether the average coffee-shop user needs that level of comprehensiveness.
Let's talk about the average user for a moment. The prompt is coming from someone who clearly understands the technical landscape — the question is sophisticated. But I'm thinking about the listener who's heard "use a VPN" and "HTTPS is everywhere" and doesn't know how to reconcile those messages. What's the practical advice?
The practical advice is: HTTPS protects the content of your web browsing from everyone between you and the website. That's the coffee shop operator, the ISP, anyone on the local network. Your bank password, your credit card number, your private messages — those are safe if you're on a properly configured HTTPS site. Look for the lock icon. If you don't see it, don't enter sensitive information.
The fact that you're doing online banking is visible.
The fact that you're doing online banking is visible. The fact that you visited your bank's website, when you visited it, how long you spent there, which pages you viewed — all of that is visible to anyone on the local network who's paying attention. For most people, in most situations, that metadata exposure is acceptable. But it's not nothing, and people should understand that it's happening.
If the metadata exposure is not acceptable — if you're a journalist, if you're in a country with surveillance, if you're researching something sensitive — then a VPN is the right tool.
Or Tor, depending on the threat model. But yes, a VPN takes the metadata off the local network and gives it to the VPN provider instead. For most threat models, a reputable VPN provider is a better custodian of your metadata than a random public Wi-Fi network.
Let's circle back to something you mentioned earlier that I want to dig into. The evil twin attack. Walk me through how that actually works in practice, because I think it's the scenario that most vividly illustrates why this stuff matters.
So you're at an airport. You open your laptop. You see a list of Wi-Fi networks. One of them is called "Airport_Free_WiFi." You connect to it. It asks for your email address or just lets you straight on. You start browsing. Everything seems normal.
The network is not the airport's network.
The network is a laptop sitting in someone's backpack three rows away. It's running software that makes it look like a legitimate access point. Your device connects to it, and it connects to the real internet — so your internet works fine. But all of your traffic passes through the attacker's machine. They can see every DNS query, every SNI field, every unencrypted connection. They can attempt SSL stripping on your HTTPS connections. They can serve you fake login pages that look like the real thing but capture your credentials.
The user has no way to know this is happening.
The user might notice that the lock icon is missing on sites that normally have it, if they're paying very close attention. But most people don't. And the attacker can make the experience seamless enough that there's no obvious sign of compromise. This is not a theoretical attack. Security researchers demonstrate it at conferences regularly. It's been used in the wild by criminals. The equipment is a laptop and free software.
A VPN defeats this entirely.
A VPN defeats this entirely for the traffic interception part. The attacker would see an encrypted tunnel and nothing else. They couldn't see your DNS queries, your SNI fields, or your unencrypted traffic. They couldn't SSL-strip your connections because the tunnel is established before any individual connection is made. The attacker's only option would be to block the VPN connection entirely, which would be noticeable — your internet would stop working. That's a denial of service, not a data compromise.
Which is its own problem, but a much less severe one.
Much less severe. And it's the kind of thing that would make you say "huh, the Wi-Fi is broken" and try a different network, rather than silently having your credentials stolen.
The VPN is effectively a hardener against the evil twin attack. But it doesn't protect against the VPN provider being compromised, or the VPN provider being the attacker.
And this is the trust conversation we need to have. The VPN provider can see everything the coffee shop attacker could see. Your browsing metadata, your DNS queries, your unencrypted traffic. They're in a position to do exactly what the evil twin attacker does. The difference is that the VPN provider has a business relationship with you, a published privacy policy, a reputation, and in many cases independent audits that verify their claims. The random person in the coffee shop has none of those things.
It's the difference between handing your mail to a postal worker in uniform versus handing it to a stranger who says "I'll deliver that for you.
The postal worker might still read your postcards. But they're accountable in ways the stranger isn't.
Let's talk about the unencrypted services question more concretely. What are the actual unencrypted protocols that a typical person's device might be using without them knowing?
I think the biggest category is mobile app traffic. The app stores have gotten better about requiring HTTPS — Apple has required App Transport Security since twenty seventeen, which enforces HTTPS by default. But developers can opt out of it for specific domains, and many do. There are still apps that load images over HTTP, that send analytics data over HTTP, that fetch configuration files over HTTP. Each of those is a potential exposure.
The user has no visibility into any of this.
The app is a black box. You can't see whether it's using encryption or not. You can't inspect its traffic without setting up a proxy and installing a custom certificate on your device. The average user has no way to evaluate the security of the apps they install.
Which is a pretty strong argument for using a VPN on untrusted networks even if you think all your web browsing is encrypted. Because your apps are doing things you don't know about.
That's exactly the argument. The VPN is a blanket protection. It doesn't matter if one of your apps is sloppy with encryption, because the app's traffic is tunneled through the VPN before it ever hits the local network. The VPN covers the apps you don't know are misbehaving.
Covering the covers.
I'm adding that one too. But yes, the VPN is a safety net for the unknown unknowns in your device's network behavior.
There's another angle I want to explore. The prompt mentions "man-in-the-middle attacks or packet sniffing on the local network." We've talked about passive sniffing — someone just listening. What about active attacks? Someone who's not just observing but tampering?
Active attacks on a local network are more powerful than most people realize. We talked about SSL stripping, but there's also ARP spoofing. ARP — the Address Resolution Protocol — is how devices on a local network figure out which physical device corresponds to which IP address. It's completely unauthenticated. Anyone on the network can send ARP messages saying "I am the router" and traffic will be routed through them. This is how man-in-the-middle attacks are typically executed on local networks.
HTTPS protects against the tampering part of that, even if the routing is compromised.
HTTPS protects against tampering with the content of the encrypted connection. If you're connected to a site over HTTPS and an attacker tries to modify the data in transit, the TLS integrity checks will detect it and the connection will fail. But the attacker can still block the connection entirely, or redirect you to a different site, or attempt to downgrade the connection to HTTP. And for non-HTTPS traffic, there's no protection at all — the attacker can modify anything.
The active attacker on the local network can't read your HTTPS traffic, but they can mess with it in ways that might trick you into doing something insecure.
They can redirect you. They can set up a proxy that terminates your HTTPS connection and establishes a new one to the real site — a classic man-in-the-middle. Your browser would show a certificate warning, because the proxy's certificate wouldn't be signed by a trusted certificate authority for the domain you're trying to visit. But users click through certificate warnings all the time. Studies have shown that a significant percentage of users will ignore certificate errors if doing so lets them access the content they want.
The user is always the weakest link in the security chain. This is not news, but it's worth remembering.
This is another place where a VPN helps. The VPN tunnel is established before any application traffic flows. An active attacker on the local network can't intercept the tunnel establishment without the VPN's authentication credentials. They can't strip the encryption from the tunnel. They can't redirect traffic inside the tunnel. The tunnel is an all-or-nothing proposition — either it's established securely, or it fails and no traffic flows.
The VPN reduces the attack surface on the local network to basically zero for passive attacks, and to denial-of-service for active attacks.
That's the technical reality. The local attacker can prevent you from using the internet, but they can't see or modify your traffic. That's a meaningful security win.
Let's address the elephant in the room. The prompt is asking about local network security, but the broader context here is that encryption has won. The web is encrypted. Messaging is increasingly encrypted. Email is slowly getting there. The trend is toward encryption by default everywhere. Are we heading toward a world where this entire conversation is obsolete?
I think we're heading toward a world where the content confidentiality problem is largely solved, and the metadata problem becomes the new frontier. And the metadata problem is harder, because metadata is inherent to how the internet works. To deliver a packet to a destination, the network needs to know the destination. To establish a connection, there needs to be a handshake. These things produce metadata by their nature. Hiding the metadata requires adding layers of indirection — VPNs, Tor, mix networks — and those layers add latency and complexity.
The encryption win is real, but it's a win on one front of a two-front war.
The second front is arguably more important for privacy. Content is what you say. Metadata is who you say it to, when, how often, from where. That's often more revealing than the content itself. You can learn someone's social graph, their habits, their associations, all without reading a single message.
Which brings us back to VPNs as a metadata protection tool. That's really what they're for now. Not protecting your bank password — HTTPS does that. Protecting the fact that you bank at a particular institution, at particular times, from particular locations.
Protecting all the other things your device does that you don't think about. The weather app checking your location. The email client syncing in the background. The fitness tracker uploading your run. The smart home app checking if you left the garage door open. Each of those is a data point. Collectively, they paint a detailed picture of your life. On a trusted network, you might be okay with that picture being visible to your ISP. On an untrusted network, you probably don't want it visible to strangers.
To answer the prompt directly: yes, even with end-to-end encryption, local network traffic has meaningful privacy exposures. The encryption protects content but not metadata, and not all services use encryption. A VPN closes those gaps by encrypting everything from the device to the VPN endpoint. But it requires trusting the VPN provider. There's no free lunch.
I'd add: the threat model matters. If you're checking sports scores at a coffee shop, the metadata exposure is probably fine. If you're a human rights activist in a repressive regime, it's definitely not. The tools are the same, but the appropriate level of caution depends on what you're protecting and from whom.
The prompt also asks specifically about traffic on the way to the router. The short answer is: it depends on the network's Wi-Fi encryption and on the application's own encryption. On a typical public Wi-Fi network with WPA2 and a shared password, the radio link is encrypted from passive eavesdroppers who don't have the password, but anyone with the password can potentially decrypt it, and the traffic is decrypted at the access point regardless. If the application doesn't add its own encryption, the traffic is effectively in the clear for anyone on the network segment.
That's the key insight that ties this all together. The radio link encryption — WPA2, WPA3 — is not end-to-end. It's a single hop. Your traffic is decrypted at the access point and then forwarded. Every hop after that, if it's not encrypted at a higher layer, is in the clear. The only way to get actual end-to-end protection is to encrypt at the application layer — HTTPS, TLS, Signal Protocol — or to tunnel everything through an encrypted VPN connection that extends the protection beyond that first hop.
It's encryption all the way down. Or rather, it needs to be encryption all the way across.
We're getting there. The trajectory is good. But we're not there yet, and the gaps are in places that most users don't see and can't evaluate. That's the argument for defense in depth. HTTPS for web content. VPN for metadata and non-web traffic. Good security hygiene for everything else.
Defense in depth is the security equivalent of wearing a belt and suspenders.
