| title | Network kill switch |
|---|---|
| description | Cut the inspected app's outbound traffic system-wide, and watch how it copes. |
During a monitored run you can block the destinations the inspected app has been contacting, then watch what it does about it.
An app that degrades gracefully when its analytics endpoint disappears behaves very differently from one that blocks the UI, retries in a tight loop, or refuses to start.
privacycommand collects every IP address the app has contacted so far in the
run, then asks the privileged helper to install a pf
anchor that drops outbound traffic to that set.
The helper:
- Writes an anchor file under
/etc/pf.anchors/. - Adds a reference to it in
/etc/pf.conf, keeping a copy of the original. - Reloads the ruleset with
pfctl -f /etc/pf.confand enablespfif needed. - Populates the blocked-address table.
Removing the kill switch flushes the anchor and rolls /etc/pf.conf back to
the copy it saved.
The helper must be installed. Without it there's no privileged path to
pfctl, and privacycommand will tell you so.
You need captured traffic first. The block list is built from destinations observed during the run. Arm it before the app has contacted anything and there is nothing to block — let the run gather traffic first.
It blocks addresses, not names. An app that re-resolves a hostname to a different IP can route around it. For a hard boundary, take the whole guest offline in VM mode.
Always lift it when you're done. The anchor persists until removed.
privacycommand restores the original pf.conf on removal, but if the app is
force-quit mid-run, check the switch is disarmed before you wonder why something
else can't reach the internet.
sudo pfctl -s info
sudo pfctl -s AnchorsIf you ever need to clear state manually, flushing the anchor and reloading the system ruleset is the same pair of commands the helper uses.