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.
Top comments (3)
Good breakdown. I think the most important point is the distinction between “client isolation is enabled” and “the device is actually isolated.”
The practical attack surface on a public network is easy to underestimate, especially with broadcast/multicast traffic and services exposed by default. Checking dns-sd and lsof is a much better reality check than assuming the café AP is configured securely.
I also like the idea of automating the defensive side. Security settings that depend on remembering to change them every time you join a new network usually fail at the human layer.
The combination of network-aware firewall rules, disabling unnecessary sharing, and treating unknown networks as untrusted seems like a much more realistic model than relying on AP isolation alone.
Nice write-up the “check what your Mac is actually exposing” approach makes this much more useful than the usual public-Wi-Fi security advice.
Thanks Kane, appreciate the close read.
The "enabled vs actually isolated" gap is exactly what caught me out. I'd always treated AP isolation as a binary I could lean on, when it's really a best-effort unicast filter with a pile of operational broadcast/multicast traffic routed straight around it.
The human-layer point is the one I keep coming back to as well. Every "just remember to enable X on public Wi-Fi" recommendation is asking people to run a checklist they'll abandon within a week — I abandon it too. That's why I went the "classify the network, then act automatically" route instead of shipping one more toggle. Glad the reality-check framing landed.
I am glad that my opinion was helpful.
I would like to get to know you better. Would you please contact me? telegram@CRDT_CTO