We Took Dummy Client Files to 11 Hotspots Across Kansas City. Here's What a Packet Sniffer Saw.
Photo by Photo by Dario Raijman on Unsplash on Unsplash
The advice is everywhere: never touch client data on public Wi-Fi. But advice is abstract, and quarter-end deadlines are not. To find out what the risk actually looks like in practice — and what a VPN does and does not fix — we spent one week conducting a controlled field test across the Kansas City metro, running simulated accounting sessions on networks any traveling bookkeeper might join.
The Setup: Synthetic Data, Real Networks
We built a dummy engagement file set: a fabricated client named "Prairie Grain Cooperative," complete with a fake EIN, synthetic transaction registers, and deliberately marked sample documents. Nothing on the laptop was real, but nothing about the file structure would look fake to anyone intercepting traffic. We also carried a second laptop running Wireshark for passive packet capture on our own sessions, and a portable hotspot to establish a controlled baseline.
Over five days we worked from 11 locations: four coffee shops, two hotel lobbies, two airport concourse gate areas, a public library, a coworking day pass, and a grocery-store café. At each, we performed the same routine — connect to the hotspot, log into a demo QuickBooks Online sandbox, sync a small file set, open a webmail session, and run a timed latency check against the QBO servers — first without a VPN, then with each of three leading business VPNs enabled.
Finding One: The Networks Are Not What They Claim
At three of the eleven locations, we found more than one network broadcasting a plausible name. A coffee shop near the Country Club Plaza offered "PlazaCoffee_Guest" and "PlazaCoffee_Guest 2" — and a scan of their MAC addresses and signal characteristics suggested the second was not part of the shop's infrastructure. An evil twin does not need to be sophisticated to succeed; it needs only to be named slightly better than the real network. A hotel lobby network named "Free_Hotel_WiFi_Premium" sat apart from the hotel's actual SSID, broadcasting on a stronger signal.
We declined to connect to the suspected impostors for obvious reasons, but their existence at more than a quarter of our stops is the finding. A finance professional choosing between two similarly named networks at gate C22 is making a judgment call with client data attached, usually while distracted and in a hurry.
Finding Two: Captive Portals Are a Trust Problem
Captive portals — the interstitial login pages that gate public networks — present their own hazard. At two locations, the portal requested an email address and, in one case, a phone number for "verification." A portal is an unauthenticated page served by an unverified network; anything typed into it is a gift to whoever controls that network. We used burner credentials throughout. Most people do not.
Finding Three: What the Sniffer Actually Saw
On our controlled capture laptop, unencrypted traffic was sparse — the modern web is mostly HTTPS, and QuickBooks Online in particular ran fully encrypted in every test. But the session was not silent. We observed DNS lookups in plaintext on networks without encrypted DNS, revealing every domain visited: the accounting platform, the document portal, the webmail provider. Device discovery traffic from other patrons' machines appeared constantly, including Windows NetBIOS broadcasts that leak a computer's name — at one gate area, a laptop named "SMITH-TAX-DESK" was announcing itself to the room.
HTTPS protects content. It does not hide that you are an accountant, on an accounting platform, at 10 p.m. on April 12. For a professional whose client list is itself confidential, that metadata is exposure.
Finding Four: The VPN Penalty Is Smaller Than the Fear
The common objection to tunneling everything is speed. Our latency measurements, averaged across all 11 locations, tell a more nuanced story:
| Condition | QBO dashboard load (avg) | File sync (10 MB, avg) |
|---|---|---|
| No VPN | 1.9 s | 41 s |
| VPN A (nearest server) | 2.2 s | 48 s |
| VPN B (nearest server) | 2.3 s | 52 s |
| VPN C (nearest server) | 2.6 s | 61 s |
The overhead of the two top performers translated to roughly 300 milliseconds on dashboard loads — imperceptible in normal use — and under 20 percent on sync times. On the airport's congested network, the VPNs actually improved consistency, smoothing out the packet loss that made raw connections stutter. The worst VPN still finished a sync a colleague could comfortably run in the background.
Notably, the fastest VPNs were those offering WireGuard-based protocols and automatic server selection. Firms evaluating VPNs for field staff should weight protocol choice and auto-connect behavior heavily; the difference between the best and worst performer in our pool was nearly double on file-heavy operations.
What We'd Tell a Bookkeeper at Gate C22
The field test converted an abstract warning into a concrete one. The risks are not hypothetical packet-sniffers reading your spreadsheets — modern encryption prevents that. The risks are subtler: impostor networks with convincing names, portals that harvest identities, metadata that announces your profession, and the sheer cognitive load of making security decisions while traveling.
A VPN does not solve everything. It will not protect a user who joins an evil twin and dismisses a certificate warning, and it cannot un-type an email address surrendered to a captive portal. What it does is collapse dozens of small per-network judgment calls into one always-on habit — and our measurements show the cost of that habit, in latency and patience, is far lower than most professionals assume.
Quarter-end is hard enough. The tunnel should be the easy part.
