Why I built an app that automatically defends your Mac's network boundary
A record of Lafine Systems Design (independent developer Tetsuharu Fujiki) investigating public Wi-Fi and dev-server exposure risks firsthand.
It started with a passing question about the Wi-Fi at a fast-food joint
One day, while working on public Wi-Fi, I suddenly wondered, "How does my Mac look to the person at the next table over on this Wi-Fi?" — and started digging in.
“Even on public Wi-Fi, client isolation (AP isolation) keeps other devices from communicating with mine, so it's safe.” I believed that for a long time, but when I looked into it, the assumption was shakier than I thought. Client isolation is not enabled on every Wi-Fi network. Even where it is enabled, a technique called “AirSnitch,” reported by the SANS Institute, can bypass it. I also only realized how much my Mac announces in plain text over Bonjour (mDNS) when I ran dns-sd and lsof myself.
The conclusion was simple. There are two countermeasures: reduce the exposed surface, and assume that people will not switch settings by hand every time the network changes. Almost nobody reviews their settings each time they arrive at a café (I don't either). So I built a macOS app that automatically tells trusted networks from the rest and automatically narrows the exposed surface on unknown networks. That was the start of RoamSwitch.
Dev servers, it turned out, had the same problem
While looking into public Wi-Fi, I also wondered about development servers, so I dug in. I had vaguely assumed that “a development server only listens on localhost, so it's safe from outside,” but in practice it varies by framework, and some defaults are counterintuitive.
next dev binds to 0.0.0.0 unless you specify hostname. python -m http.server also listens on all interfaces by default. Vite defaults to localhost, but everyone has added --host to test on a real phone. There is also CVE-2023-34092 (path traversal, CVSS 7.5) that targets exactly that. With Docker's -p, a port can even be published on 0.0.0.0 bypassing the host's firewall settings.
This led to the same conclusion. Rather than having people remember to close ports every time, it is more realistic to automatically block access from outside the moment you join an untrusted network. In fact, this is one of the most commonly reported ways RoamSwitch is used. It passively audits open ports and reports the risk, and on unregistered networks it blocks access from the external LAN with the kernel's packet filter.
Lafine Systems Design / Independent Developer
RoamSwitch's firewall control (pf/socketfilterfw), ARP spoofing detection and privileged helper (XPC) are based on practical experience. I worked as an SE at a foreign-owned IT company and at a major electronics manufacturer group, and after going independent I provided ASP services for government agencies, universities and research institutions. I now develop “RoamSwitch” on my own and write about what I find out on Zenn.
Published in a form you can verify
- RoamSwitchKit (MIT-licensed open-source SDK, GitHub)
- roamswitch-mcp (source of the MCP server and detection logic, GitHub, MIT)
- RoamSwitch security whitepaper (every section public)
- Measurement of Zero Telemetry outbound traffic (as of 1.4.7. tcpdump plus process attribution, PASS with a reproducible script. The current version will be re-measured)
- Changelog (GitHub, shipped continuously)
- Research written up as technical articles on Zenn
- Notes on running a security product solo — on note (JP)
- English write-ups and essays on dev.to
For legally required disclosures such as the operator's name, address, and payment methods, see the Act on Specified Commercial Transactions disclosure.