A Japanese version of this is on Zenn.
I was working from a café the other day and idly wondered: on this Wi-Fi, what does my Mac actually look like to the person at the next table? So I went and looked into it.
"Public Wi-Fi is fine as long as client isolation (AP isolation) is on, because then you can't talk to other devices" — that's the explanation you hear a lot, and I believed it for years too. Turns out the premise is shakier than I thought, so here's what I found.
Client isolation isn't necessarily on in the first place
Baseline fact: client isolation is a feature where the AP filters unicast forwarding between clients on the same SSID. It's not a legal requirement and it's not mandatory in any standard. On a cheap router or a small shop's setup, it's routinely just left off. And you generally can't tell from the outside whether it's on.
OK, but if it is on, am I safe? Also apparently not
This is the part that made me go "huh." The SANS Institute wrote up a technique called AirSnitch that shows client isolation can be bypassed even when it's enabled (SANS, SecurityWeek). Roughly:
- Abusing the GTK. Isolation stops unicast client-to-client forwarding, but broadcast traffic that the network needs operationally — ARP, DHCP, mDNS — keeps getting forwarded. If you stuff a unicast payload inside a broadcast frame encrypted with the shared GTK, it goes through this gap.
- L3 bounce via the gateway. On a network without DHCP snooping or Dynamic ARP Inspection, the source IP isn't validated. Spoof the victim's IP, send to the gateway, and routing sends the traffic back down to the victim.
- Rewriting the MAC table. An AP has a forwarding table like a switch does. Spoof a MAC and you can overwrite the entry.
None of this breaks the encryption itself — it's that the isolation implementation is architecturally weak. The SANS piece says it flatly: "AP isolation alone is insufficient segmentation." The unsettling bit is that you don't need enterprise-grade knowledge for any of it.
macOS is doing a fair amount of talking anyway
Bypass or no bypass, your Mac announces plenty to everyone on the network just going about its normal business.
Bonjour (mDNS, UDP 5353) advertises file sharing, screen sharing, AirDrop candidacy, printers, and so on — in cleartext. Anyone on the same Wi-Fi can see your device name and service info.
You can check what's actually being broadcast from a terminal:
# Enumerate Bonjour services on the local network
dns-sd -B _services._dns-sd._udp local.
# See which ports your own Mac is listening on
sudo lsof -i -P | grep LISTEN
Try it once in a café and it's surprisingly talkative (not that "fun" is the right reaction).
AirDrop has its own history here — TU Darmstadt's SEEMOO lab flagged it at USENIX Security 2019. The authentication handshake exchanges hashes of your phone number and email, and those hashes turn out to be fairly easy to brute-force back. The team proposed a privacy-preserving version called PrivateDrop in 2021, but for backward-compatibility reasons it reportedly isn't fully resolved as of writing.
So what do you actually do
After all this, it seems like there are really only two moves.
One is just reduce your exposure: turn off sharing features you're not using, and look at your firewall state yourself under System Settings > Network > Firewall (the default varies by OS version and configuration profile, so I won't assert what it is — check yours).
The other is to stop assuming you'll flip the switches yourself every time the network changes. Honestly, nobody re-reviews their settings every time they walk into a café. I don't. So a setup that automatically distinguishes trusted networks (home, office) from everything else, and quietly narrows your exposure on unknown ones, is what actually works in practice.
I happen to have built a macOS app that automates that second part — RoamSwitch. The moment you connect to a network that isn't on your registered list, it stealths the firewall and stops sharing and AirDrop. No magic — it just does the "reduce your exposure" part for you, instead of you.
Start by poking at your own setup with dns-sd and lsof. It's a good way in.
