Sending Files on Public Wi-Fi: Real Risks, Not Scare Stories
The standard warning (“never do anything sensitive on public Wi-Fi”) was excellent advice in 2012, when most web traffic was unencrypted and a laptop in the corner could read everyone's email. It is mostly obsolete. Nearly all traffic is now encrypted end to end between your device and the server, and an encrypted file transfer is encrypted between the two devices. What remains is a shorter and more specific list of risks, which this article lays out without the drama.
What a person on the same network can do
| Attack | Still works in 2026? | Against an encrypted transfer |
|---|---|---|
| Sniffing traffic (reading packets off the air) | Yes, trivially, on open networks | Sees encrypted packets: sizes, timing, endpoints. Not contents, not file names. |
| Evil twin (a fake hotspot with the café's name) | Yes | Same as sniffing, plus the attacker is your router: they can block, redirect and see all your endpoints. |
| Downgrading HTTPS to HTTP | Mostly no — browsers and HSTS refuse | Not applicable; WebRTC has no unencrypted mode to downgrade to. |
| Impersonating the other end (man-in-the-middle) | Only if the introduction step can be tampered with | Detectable: the safety codes on the two devices will not match. |
| Captive-portal phishing (fake login page) | Yes | Unrelated to the transfer; steals whatever you type into the portal. |
What is actually protected
A WebRTC transfer encrypts the data channel with DTLS, with keys negotiated between the two browsers. Someone capturing every packet on the café network gets ciphertext and nothing else; the Wi-Fi password, or its absence, does not enter into it (the details). The same holds for any HTTPS site and any modern messaging app. The era of reading strangers' files off the air is over.
What is still exposed: metadata
Encryption hides content, not activity. An observer on the network can see that your device exchanged 800 MB with a particular address at 14:32, and on a direct peer-to-peer connection, that address is the other person's. An evil-twin operator sees the same for every site you visit. This is the honest residual risk of public Wi-Fi, and its severity depends entirely on whether “who talked to whom” is sensitive for you (the full map). For most people, it is not. For a journalist meeting a source, it is, and a VPN (which moves the observer's view to “this device talked to a VPN server”) is the mitigation.
The one attack that matters: the substituted peer
The only way for an attacker to read an end-to-end-encrypted transfer is to be one of the ends: intercept the introduction so that you connect to them, and they connect to your friend, relaying in the middle with two separate encrypted sessions. This requires control of the introduction path: a hostile network is one way to get that. It is exactly what the safety code exists to catch: both devices derive a short code from the keys of their session, and if an attacker sits in the middle, there are two sessions and two different codes (how). Compare the codes out loud, over a call, or by looking at both screens; a match ends the question.
What changed between 2012 and now
| 2012 | 2026 | |
|---|---|---|
| Web traffic encrypted | A minority of sites; login pages only, often | Effectively all of it; browsers warn on plain HTTP |
| Session hijacking (stealing a login cookie off the air) | Trivial with a browser extension | Blocked by HTTPS and HSTS on every major site |
| Downgrading a site to HTTP | Routine attack | Refused by browsers for sites with HSTS, which is most |
| Messaging apps | Mostly unencrypted or provider-readable | End-to-end encrypted by default on the major ones |
| Wi-Fi itself | Open or WEP/WPA with shared keys | WPA3 and per-client encryption spreading; still often open |
| What an attacker on the network gets | Your email, your sessions, your files | Metadata, and whatever you type into a fake portal |
How to spot an evil twin
- Two networks with the venue's name, one without the password the staff gave you.
- A portal that asks for more than the venue would: a card number, an account password, a social login for “verification.”
- A browser certificate warning on a site that never shows one. Do not click through; that warning is the attack being noticed.
- The network appears when the venue is closed or in a place with no obvious source.
Asking the staff for the exact network name takes ten seconds and defeats most of these. An evil twin cannot read an encrypted transfer any more than the real network can; what it can do is redirect you to a fake page or collect what you type into one.
What a VPN adds here, and what it does not
On public Wi-Fi a VPN moves the local observer's view from “this device talked to these fifteen addresses” to “this device talked to a VPN server.” That is a real gain if the metadata matters to you. It does not add protection to the contents of an encrypted transfer, which were already unreadable, and it can push the transfer onto a relay and slow it down (the mechanics). Use one for the metadata reason, not because you think the file needs it.
Captive portals: the one place to be careful
The venue's login page is the least protected thing you will see on public Wi-Fi. It is often served without encryption, it is exactly what an evil twin imitates, and it is where people type real email addresses and, occasionally, real passwords. Give a portal only what it needs (a throwaway email if it insists on one), and never sign in to an account from a portal prompt. Once past the portal, the rest of your traffic is encrypted by the sites and apps themselves; the portal is the moment that is not.
What the venue itself can see
Whoever runs the network is a permanent observer, not an attacker who has to bother setting anything up. They see every destination address, the domain names in certificate handshakes, DNS lookups unless your device uses encrypted DNS, and how much went where and when. They do not see contents. For a file transfer that means they can tell a device exchanged 800 MB with a particular address at 14:32 — the same metadata picture as any observer, sitting on the router instead of a laptop in the corner (everything that leaks, by party).
Do and do not, in 2026
| Do | Do not |
|---|---|
| Confirm the network name with a person | Join the first network with a plausible name |
| Compare the safety code on a transfer | Skip it because “it is encrypted anyway” |
| Use encrypted DNS on your device | Type account passwords into a portal |
| Use a VPN if who-you-talked-to is sensitive | Expect a VPN to make the file safer than it already is |
| Click away from certificate warnings | Click through them |
“It is WPA3 now, so it is safe”
Newer access points offer per-client encryption even on networks with no password (Enhanced Open) and stronger protection on those with one (WPA3). That is a genuine improvement: on such a network a laptop in the corner can no longer read other clients' traffic off the air at all, encrypted or not. It does not change the two things that still matter here. The venue's router still sees every destination and every packet size, because it is the router; and an evil twin is by definition a different network, whose radio encryption protects you from everyone except its operator. The transfer's own encryption is what stands between the file and all of them, on every kind of network.
Two checks that actually matter
- Compare the safety code. Ten seconds, and it defeats the one attack encryption alone cannot.
- Confirm the network name with a human before joining, and never type a real password into a captive portal. Evil twins and portal phishing are the attacks that still pay off on public Wi-Fi, and neither of them is about the file transfer.
What you can stop worrying about
- The contents of an encrypted transfer being read. They cannot be.
- “Open” versus password-protected Wi-Fi for encrypted traffic. The Wi-Fi password protects the radio link; your transfer is already encrypted above it.
- Needing a VPN to transfer a file safely. A VPN hides metadata and helps on hostile networks, but it is not what protects the file, and it can force your transfer through a slower relay (why).
Public Wi-Fi is a place where you should check who you are talking to. It has not been a place where strangers can read your files for a long time.
Primary sources
- RFC 8826: Security Considerations for WebRTC, the threat model that assumes a hostile local network.
- RFC 8827: WebRTC Security Architecture, which makes DTLS mandatory and ties the keys to fingerprints exchanged in signaling.
- RFC 6797: HTTP Strict Transport Security (HSTS), the reason a network attacker can no longer downgrade a participating site to plain HTTP.
- RFC 8110: Opportunistic Wireless Encryption, the mechanism behind Wi-Fi Enhanced Open on password-free networks.
- Wi-Fi Alliance: Security: the industry overview of WPA3 and Enhanced Open.
