macOS Sonoma Network Privacy: What Changed

macOS Sonoma shipped with a handful of network-privacy changes that mostly flew under the radar — partly because Apple talks about privacy in big strokes and partly because the changes most relevant to power users are buried in network extension behavior, randomized addressing, and how the OS treats VPNs and content filters. If you upgraded from Ventura and noticed your VPN behaving oddly, your captive portal getting weird, or apps you don't remember installing showing up in network logs, this is probably why.

This post is a working list of the macos sonoma network privacy changes that actually mattered, what survived into Sequoia, and what you can do about each one. Where the documentation is thin or the behavior is murky, I'll say so rather than guess.

Private Wi-Fi Address improvements

Apple introduced randomized MAC addresses (Private Wi-Fi Address) in earlier macOS versions, but Sonoma tightened the implementation in ways that matter.

What changed

• Per-network rotation behavior. Sonoma is more consistent about giving each network its own randomized address and keeping that address stable across reconnects to the same network.
• Hardware reservation handling. Networks that use MAC-based DHCP reservations or bandwidth caps started behaving more predictably because the address persists per network rather than rotating mid-session.

What this breaks

Some captive portals — the kind you find in hotels, conference centers, and coffee chains — still use MAC addresses to track sessions and bandwidth quotas. With randomized addressing on, you may need to re-authenticate more often than expected. On networks where the captive portal is buggy, you may not be able to authenticate at all without disabling Private Wi-Fi Address for that specific network.

How to fix it without losing privacy elsewhere

System Settings → Wi-Fi → click the network in question → Details → Private Wi-Fi Address. You can turn it off per network, leaving randomization on for every other network you use. Don't disable it globally — disable it only on the one captive portal that's broken.

Network filter API tweaks

Sonoma made adjustments to the NetworkExtension framework, which is what apps like Little Snitch, LuLu, and corporate endpoint security tools use to inspect or filter traffic.

What changed

• Stricter handling of how content filters interact with system traffic
• Some private API surface was removed or restricted
• Filter providers had to update for the new behavior; some lagged

What you might have noticed

• A favorite network filter prompted you to update or stopped working entirely after upgrade
• DNS resolution behaved oddly until the filter was updated
• Performance regressed temporarily on machines with multiple network extensions installed

If you're running a current version of any major filter tool, this is mostly behind you. If you're holding onto an old version because "it still works," it may be the cause of intermittent network problems on Sonoma.

System extension behavior

System extensions — the modern replacement for kernel extensions — got tighter approval flow on Sonoma, especially for ones that handle network traffic.

What changed

• More explicit user approval prompts when an extension wants to filter network traffic
• Extension upgrades sometimes require re-approval rather than silently rolling forward
• The "Allow in the next 30 minutes" flow is more prominent

Practical implications

If you upgraded a VPN client or firewall on Sonoma and suddenly nothing worked until you walked through System Settings → General → Login Items & Extensions, this is why. Annoying once, valuable forever — you now know exactly what's intercepting your traffic.

DNS and resolver privacy

Sonoma continued the trend of strengthening DNS privacy, with a few practical implications.

What was already there

• iCloud Private Relay (when subscribed) routes most Safari traffic through two relays so neither sees both your IP and your destination
• Encrypted DNS (DoH/DoT) configurable via system profiles

What's worth knowing

• If you use a custom DNS resolver (1.1.1.1, NextDNS, your own Pi-hole), Sonoma respects it more reliably across network changes
• Apps that use the system resolver inherit your DNS choice automatically
• Apps that bundle their own DNS client (some browsers, some chat apps) bypass your settings, and there's no way to force them otherwise without a network filter

This last point is why a per-app bandwidth view matters even when you have DNS configured well: the only way to know whether an app is making the connections you'd expect is to watch what it's actually sending.

See what your apps are actually doing on the network

ova shows per-app bandwidth with helper processes folded under their parent. Local-only, no telemetry, no account, ~3 MB.

Download for macOS

Local Network access prompts

This is the change most users actually noticed. Sonoma got more aggressive about prompting for "Local Network" access when an app tries to discover other devices on your Wi-Fi.

What's covered

• mDNS / Bonjour discovery
• SSDP (used by streaming receivers, some smart home gear)
• Direct connections to local IP ranges

What you'll see

A prompt like "App X would like to find and connect to devices on your local network." Granting it is fine for apps that legitimately need it (Spotify discovering AirPlay receivers, IDEs discovering test devices). Denying it is fine for apps that don't.

You can review and revoke later: System Settings → Privacy & Security → Local Network.

What survived into Sequoia

Most of the Sonoma changes carried forward into macOS Sequoia with minor refinements:

• Private Wi-Fi Address per-network rotation: still there, still recommended on by default
• Tighter NetworkExtension API surface: still there, with further refinements
• System extension approval flow: still there, with the same UI patterns
• Local Network access prompts: still there, with the same per-app revocation in System Settings

If you skipped Sonoma and went straight from Ventura to Sequoia, you'll encounter all of these for the first time at once. The fixes and habits described above all apply.

What's honestly murky

A few things I won't claim to know definitively:

• The exact algorithm for Private Wi-Fi Address generation. Apple has not fully documented the rotation policy and changes between point releases.
• Background app network behavior under low-power conditions. macOS deprioritizes background traffic in various conditions, but the exact thresholds are not public.
• The full list of NetworkExtension API changes. Apple's release notes are partial. Real changes get discovered when third-party tools break and developers post about them.

If you read a confident blog post claiming exact details on any of these, treat it as informed speculation unless it cites Apple documentation.

Practical macos sonoma network privacy steps to take today

For users on Sonoma (or Sequoia, since most of this carried over):

1. Audit your installed network extensions. System Settings → General → Login Items & Extensions → Network Extensions. Know what's there. Remove anything you don't recognize.
2. Review Local Network grants. System Settings → Privacy & Security → Local Network. Revoke for apps that don't need it.
3. Check Private Wi-Fi Address per network. It should be on for home, on for most networks, and off only on specific captive portals where it breaks authentication.
4. Run a per-app bandwidth monitor. This is how you'll notice when an app starts making connections it didn't make before.

The fourth point is the one most people skip. Privacy controls are most useful when paired with visibility. macOS gives you a lot of toggles; it does not give you a great view of what your apps are actually sending. That's the gap ova fills — a passive, menu-bar-resident bandwidth monitor that shows live rates and history per app, with helpers folded under their parent app, sampled at about 1 Hz, with no cloud dependency.

Wrapping up

The macos sonoma network privacy story is mostly incremental, mostly good, and mostly invisible until something breaks. The breakage that does happen tends to come from:

• Old VPN/firewall versions that didn't update for new APIs
• Captive portals that don't handle randomized MAC addresses well
• Apps that used to silently access the local network and now have to ask

The fix in each case is a five-minute settings audit, not a reformat. If you upgraded recently and felt like the network "wasn't quite right," you probably tripped over one of these. Walk through the practical list above, install ova or any equivalent passive monitor so you can see what your machine is doing, and the network experience usually clicks back into place. macOS 14 and later are well supported by anything modern, including ova at about 3 MB on disk, runs on Apple Silicon and Intel, all data stays local.