DEV Community: Tetsuharu Fujiki

You're probably overestimating public Wi-Fi 'client isolation'

Tetsuharu Fujiki — Fri, 28 Aug 2026 14:07:55 +0000

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.

The app was the easy part. Getting anyone to trust a security tool from a solo dev wasn't.

Tetsuharu Fujiki — Fri, 28 Aug 2026 10:36:18 +0000

A Japanese version of this is on Note.

I build a Mac app that automatically tightens your network security when you're on a Wi-Fi you don't trust — coffee shop, airport, conference. The moment you join a network you haven't marked as trusted, it closes the firewall, stops the sharing services, and blocks any dev-server port you left listening on 0.0.0.0. Back on your trusted home or office network, it undoes all of it.

The engineering wasn't hard. Poke pf, listen for network-change events from the OS, stop the sharing daemons with launchctl. I had something working pretty quickly.

The hard part started when I decided to ship it as a product. And it started before "will it sell" — I got stuck one step earlier, at "will anyone actually install this?"

For a security tool, trust is the bottleneck

When I write out what I'm actually asking people to do, it's this:

An unknown individual built a piece of software that includes a root-privileged background process, pitches it as something that will cut off your network traffic, and ships it as a direct download.

Spelled out, even I don't want to install it. And the people with healthy suspicion — the engineers and privacy-minded folks who need this most — are exactly the ones who stop right here.

A product from a big company gets to borrow that company's brand to cover this. A solo dev has none of it. So I ended up having to build every piece of "here's why you can trust this" myself. Here are the walls I hit, what I did about each, and — honestly — what I still haven't solved.

Wall 1: you can't see inside

What I did:

Published an architecture & security whitepaper. The complete list of operations the privileged helper can perform, how it touches pf, every outbound network path, the crypto, the threat model and the explicit non-goals. Not "trust me" — written at a level you can check against the code.
Open-sourced the MCP server and the detection logic (MIT). So you can read, in code, exactly what it hands to an AI client and that it sends nothing out.
Wrote a verify script. A short read-only shell script that checks the signature, notarization, entitlements, and current state against an installed copy.

The funny part: after open-sourcing it I got nervous — people are going to go looking for bugs now — so I fuzzed my own JSON-RPC parser before anyone else could. And immediately hit a crash inside Apple's JSON parser (a stack overflow on deeply-nested JSON objects; try? doesn't catch it — the process just dies). If I hadn't published the code, I probably never would have looked. Fixed in the next release.

Wall 2: distribution economics and the Apple tax

I can't ship on the Mac App Store — the privileged-helper design won't pass review. So it's direct distribution: Developer ID signing, submit to Apple's notary service on every build, staple. That's a $99/year Developer Program membership, and a notarization round-trip on every release.

What I did:

Collapsed sign → notarize → package → update the appcast → deploy into one script. A manual checklist always drops a step somewhere.
SMAppService.daemon (registering the helper) won't register unless the app is in /Applications. The first-run "approve this in System Settings" friction is still not fully solved.

Wall 3: the support surface of an app that does things

This app blocks ports and cuts off traffic on its own when conditions are met. Useful — but the flip side is a structural stream of "hey, X stopped working" tickets. Your dev server isn't reachable from your phone anymore, that kind of thing.

What I did:

Every block ships with a "lift it" button and a reason. After applying, it reads the rules back with pfctl and, if that failed, the modal says so honestly: "traffic is not stopped yet — turn off Wi-Fi now."
The automatic guards default toward opt-in early on.

Still, as one person, support is basically a 24/7 on-call rotation. That one's a scale problem, not something I can design away.

Wall 4: you can't say "we protect you"

If your security-product copy says "we'll keep you safe," that's a problem both legally and ethically. When ransomware gets through, it becomes "but you said you'd protect me."

What I did:

The whitepaper and the site both state plainly: one layer of defense-in-depth, not a guarantee.
"Completely prevents X" is off the table as copy. I actually caught the landing page claiming everything "stays inside a secure sandbox" — the app deliberately doesn't use the App Sandbox, so that was just false. Fixed it, in all ten languages.

Wall 5: pricing a fear product

I didn't want to do the "scare them, charge a premium" thing. But price it too low and it's "isn't free security software kind of suspicious?"

What I did:

One-time $19.99, no subscription. Aimed at the buy-once crowd who are tired of subscriptions. "A coffee and a snack, once, and it's handled from now on."
A free tier so people can install it and watch what it does first. The paid value is framed as "it acts for you, no clicks" rather than "it warns you."

Wall 6: Zero Telemetry means I go blind

I decided the app sends nothing externally. That's core to the trust story, non-negotiable. But the cost: no funnel analytics. Where people drop off, which features get used, A/B tests — none of it.

What I did:

Accepted it. Download counts, checkout, referrers, GitHub stars, article response — run the business on that coarse data.
Wrote down, explicitly, that "add telemetry" is a lever I'm choosing not to pull.

Wall 7: "what if the developer disappears?"

This is the purchase objection specific to security software. The thing that sits resident and defends you might, one day, stop being maintained.

What I did:

License activation is fully offline. Ed25519 signature + a device hash, so if the activation server ever goes away, activated Macs keep working.
Working toward an end-of-life policy (final build stays available, signed, indefinitely). Open-sourcing the key components is part of the same insurance.

What I still haven't solved

A third-party security review. I test it myself and show my work, but an independent set of eyes hasn't looked yet.
Just being found at all. Unknown, near-zero ad budget. You can build something good and still not get discovered. Separate post.
The coarse metrics are here to stay by design.
Being one person. Response time, sick days, bus factor.

Still

"Won't publishing the code just get you exploited?" — I get the worry, I had it too. But having actually done it: nothing that isn't already in the shipped binary got exposed, and because I expected people to read it, I actually tested the thing properly.

Shipping a security product as an individual is, I think, a job where "building the features" is the smaller half and "assembling the trust" is the bigger one. That's what the barrier really is — and also, it turns out, something a solo dev can do.

The app is RoamSwitch. The full design is in the security whitepaper; the open-source MCP server is here.