As if we didn’t have enough protections listed in Privacy & Security settings, macOS Sequoia added another for Local Network. Unlike the rest, this came with a sting in its tail: there has been no way to reset an app’s settings. Once an app has been added to the list, all you can do is turn its access off or on, until macOS Golden Gate 27.2, expected to be released early next week. That is promised to let you add and remove apps from the Local Network list, at long last.
One reason for this long delay is that Local Network privacy is nothing to do with TCC, Transparency Consent and Control, unlike other privacy controls, but is implemented as a packet filter by the Network Extension framework. Location Services are also handled and implemented separately.
Base rule
Any process on your Mac that tries to make a connection to a local network address, to send or receive network packets without being forwarded by a router, now requires the privilege to do so. Without that, the system will block it.
All non-exempted apps and other processes start without any privilege. Those that try to make a local network connection result in the user being prompted to allow or deny their access. Your decision is then recorded in that app’s new entry in the Local Network section, and you control that to allow or deny its future access. For that to happen, the responsible app needs an additional entry in its property list to explain why it requires that access, something that should appear in any prompt.
As with other privacy controls in macOS, this is applied for each user individually.
Major exceptions
In macOS, the following are automatically given local network access and don’t appear in Local Network privacy settings:
- any daemon (except agents) started by
launchd - any process running as root
- command tools run from Terminal or using SSH, including their child processes
- traffic from Safari and WebKit (WKWebView)
- access to a local DNS server or network proxy
- high-level services using Bonjour internally, including AirPlay, printing, device discovery and accessory setup.
Those exempt the majority of processes likely to be run by users.
Listening for and accepting incoming TCP connections doesn’t require any privilege, nor does receiving an incoming UDP unicast. Resolving a local DNS name ending in .local does require privilege, though, as do all Bonjour operations other than those exempted above.
Configured exceptions
You can also configure exceptions to Local Network privacy by adding them to com.apple.network.local-network settings using the command tool defaults.
There are two settings available, AllowedEthernetLocalNetworkAddresses to apply to networks over wired Ethernet, and AllowedWiFiLocalNetworkAddresses for Wi-Fi. Apple provides two examples to illustrate this, both of which will exempt the 169.254/16 network over their respective interfaces:
sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "169.254.0.0/16"
sudo defaults write com.apple.network.local-network AllowedWiFiLocalNetworkAddresses -array "169.254.0.0/16"
Unlike the rest of Local Network privacy, those are set globally and not per-user.
Ad hoc signed code
Apps and other code are tracked for their Local Network privacy setting by their code signature. Although that should work fine for code signed using an Apple-issued signing identity, such as a Developer ID Application certificate, it may not be reliable with code that is ad hoc signed. Tracking also uses the UUID of the main executable code. If there is no UUID, then it may act unpredictably.
Control in macOS 27.2 and later
From its introduction over two years ago in macOS Sequoia, there has been no way of resetting an app’s Local Network privacy. This is about to change in macOS 27.2, where you can now add and remove apps from the list in Privacy & Security settings. At last.
