I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. The danger of public Wi-Fi moved from the wire to the network you join. Passive sniffing is mostly dead, killed by TLS. The live risks are the network itself: evil-twin hotspots, fake login pages, and the person sitting behind you.
The warning was earned, in 2010
October 2010. Developer Eric Butler walks onto a stage at the ToorCon security conference in San Diego and demos Firesheep, a Firefox add-on that lets anyone on an open wireless network hijack other people's sessions on Facebook, Twitter, Google and Amazon. The sites had encrypted the login page and left the session cookie travelling in plain text. Butler's line from the talk: "On an open wireless network, cookies are basically shouted through the air." Nearly 50,000 people downloaded it within days.
The old advice was right for that world: open networks everywhere, logins encrypted, everything after the login exposed. The industry answered by encrypting all of it, all the time. Mostly, it worked.
What TLS changed for email
Email got there early. In March 2014, Gmail's security lead Nicolas Lidzborski announced that Gmail would always use an encrypted HTTPS connection for checking and sending mail. HTTPS had been the default since 2010; now it was mandatory, with the explicit point that nobody could listen in on messages between users and Gmail's servers on public Wi-Fi. The Internet Society summed it up: the change removed the ability to view messages "on the wire". Gmail's help page still states it plainly: all Gmail messages use TLS automatically, and almost all major email services do the same.
Outlook runs the same way: Microsoft's documentation says all customer-facing servers negotiate a secure TLS session with client machines, with Exchange using TLS 1.2 with 256-bit cipher strength for Outlook, Teams and Outlook on the web. Your mail app is the same: IMAP on port 993 or SMTP on port 587, both wrapped in TLS by requirement, as Google's developer docs spell out for Gmail. For what each provider actually guarantees, see Is Gmail Safe? and Is Outlook Safe?.
The rest of the web caught up. In October 2026, Chrome made asking permission before any insecure HTTP connection the default for everyone, possible because nearly 95% of desktop users never see an HTTP warning in a given week. The Firesheep era ended when encryption stopped being the exception.
One caveat: TLS hides the contents of your mail, not the fact that you are reading mail. The network operator can still see which domains you visit, roughly. That is metadata, not your inbox. Encrypted contents, visible destinations.
The danger moved to the network you join
Encryption protects what travels on the connection, but it says nothing about whether the network you joined is the café's. That gap is where the risk lives now.
An evil-twin attack works like this. Someone sits near a busy café, airport or hotel, copies the venue's network name, and broadcasts a fake access point with a stronger signal. Your phone cannot tell the two apart. Once you connect, everything routes through their machine. Kaspersky notes this can be done with a smartphone and readily available software, and Okta's breakdown names the usual next step: a fake login page copying the venue's. Comparitech's guide is blunt: HTTPS gives only partial protection on a hostile network, because the attacker can steer you toward a convincing fake login page, or ask you to install a certificate that lets them decrypt your traffic.
You mostly cannot spot an evil twin. That is the point. The useful signals are behavioural: two networks with the same or nearly identical names, your device dropping and reconnecting for no reason (deauthentication attacks do that on purpose), or a sudden browser certificate warning. Comparitech's prevention list is short: verify the network name with staff, disable auto-connect, treat every public network as hostile. The attacker is counting on exactly that habit: per the Decision Data survey Okta cites, 82% of people connect to any free Wi-Fi available when they are out. I have no real-world figure for how often evil twins actually get run; cheap and documented is the strongest honest claim. Assume the network wants something.
Captive portals, real and fake
The page that appears when you join hotel or airport Wi-Fi, asking you to accept terms or enter a room number, is a captive portal. Real ones are fine. Fake ones are cheap to build, and they arrive at the exact moment you expect a login page.
Here is what a captive portal should never ask for, from hide.me's guide to fake captive portals: your personal email password. No hotel, airport or café needs the password to your inbox to give you internet. That request is a strong phishing warning. Do not enter it; verify the network with the venue's staff in person, or switch to mobile data. The same applies to unexpected requests to install a certificate, a device-management profile, or an app "for Wi-Fi access". A rogue root certificate changes which authorities your device trusts, which is how an attacker reads traffic HTTPS would otherwise protect. A padlock is no reassurance either: a fake portal can quite plausibly use HTTPS with a valid certificate, per the same guide.
If a captive portal asks you to install a security certificate, a device profile, or an app to get online, do not agree. Legitimate venues never require this, and a rogue certificate lets an attacker read traffic that would otherwise be encrypted. Verify with staff in person, or switch to mobile data and leave the network.
The person behind you
The lowest-tech risk on this list is also the most common. Shoulder surfing needs no tools, no network access and no skill: someone simply reads your screen in a crowded café or on a train. No encryption in the stack defends against it, because the mail is already decrypted by the time it reaches your eyes. Sit with your back to a wall, shrink the text, and lock the screen the moment you stand up. Unglamorous advice. It works.
Aliases guard the address, not the connection
This is where I have to be straight about my own product, because the temptation to over-claim is what this piece exists to resist. An email alias changes the address a sender holds. It encrypts nothing, verifies no networks, stops no fake hotspot. If you check mail on a hostile network, the alias is as exposed as the real address for that session. Aliases work at the identity layer: one forwarding address per site, so a breach of one site cannot hand attackers the address you use everywhere else. For the connection layer, the answer is a VPN or mobile data. Two tools, two jobs. Neither does the other's.
What actually protects the connection
The fix depends on which risk you are fixing:
| What can go wrong | What stops it |
|---|---|
| Someone passively sniffing your mail off the air | TLS on every provider connection, already on by default; nothing to do |
| A fake hotspot using the venue's name | A VPN, or mobile data; verify the network name with staff; turn off auto-join |
| A fake login page asking for your credentials | Never type your email password into a Wi-Fi login page; never install its certificates or profiles |
| Session hijacking on a network the attacker controls | A VPN; keep your apps and OS updated; sign out of sessions you do not need |
| Someone reading your screen | Positioning, smaller text, a privacy filter; lock the screen when you stand up |
The official guidance agrees: the NCSC advises that on public or shared Wi-Fi you should consider using a VPN to secure your connection and avoid snooping on the link. CISA's mobile guidance tells users to avoid public Wi-Fi unless they can take the necessary security measures, and its public Wi-Fi tip card starts from the premise that hotspots are not always secure. Nobody in that list says never use café Wi-Fi. They say: assume the network is hostile and act like it.
A short checklist for the next café visit
If you remember nothing else, remember the order of operations.
- Decide whether you need the café's network at all, because your phone's hotspot removes the entire evil-twin category in one move.
- If you join the venue's Wi-Fi, confirm the exact network name with a person who works there. Turn off auto-join.
- Do sensitive sessions (password changes, banking, work systems) on the VPN or mobile data.
- Treat the login page as guilty until proven innocent. Room numbers and voucher codes are normal. Your email password and a certificate install are not.
- Lock the inbox itself down regardless of network: passkeys and a second factor first, as the email account security guide walks through, because no network setup saves an account with a reused password.
- When you hand sites your address, use a separate alias per site, so the next breach of a café loyalty programme costs you one address, not your identity.
The old warning was not wrong. It was written for 2010, and that web is gone. What replaced it is a narrower, more specific set of risks, and they all answer to the same question: what can go wrong on this network, and what does my setup actually defend against.
Top comments (0)