Time to dig in, I guess.
macOS content filtering in Big Sur is no longer able to intercept apps on the exclusion list shipped by Apple, and is akin to 'iptables --uid 501' or 'iptables --command firefox-bin' (actual syntax may vary).
The content filtering API can see which user/app originated the traffic, as it's running higher up in the stack; the packet filtering API cannot, as it's running lower down in the stack.
Apps such as Little Snitch allow you to filter network traffic per-application, which can't be done with PF; you need CF for that, and CF no longer extends to Apple core system processes in Big Sur.
Mullvad's blocks are done imprecisely with PF (presumably they deny 17.0.0.0/8), which is why their blocks break various functionality such as the Mac App Store or:
> For example, the keyboard sometimes takes longer to wake up from sleep mode. Or, in certain situations, the Mullvad app takes longer to detect that the computer is online.
And while they note that it's possible to punch exceptions into the firewall, those exceptions can't be granted per-use, only per-IP.
Operating a system in PF deny-all default would cure this, as long as LS carefully curated a list of PF allows.
It's possible there are external constraints preventing more widespread use of PF, like "Is this allowed on Mac App Store?".
I happen to not use app-level filtering these days, only pi-hole and and packet-firewall stuff, so I guess I'll be unaffected if I ever upgrade.
Bypassing app-level filtering, though, that sucks.
Trivially is defined as 'click an OK button in a dialog' as the CF permissions process works in Big Sur today.
Malware could still block anti-malware checksum updates with PF, but that requires sudo/root which is 'less easy' than the one-click CF approval process, and PF blocks break so many things on the system that malware can't get away with it without triggering a call to technical support.
(I personally think that much of the issue here is 'macOS background updates can cause $$$$ cellular data drain over wifi-tethered cellular', and that the absence of Low Bandwidth mode in Control Center is one thing that drives users towards these third-party content filters, when they might otherwise not need a third-party product at all.)
A VPN simply gives you access to a local network. A specific use of a VPN is masking your internet traffic as if it came from that local network, but there are many uses besides it.
The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.
This sentence suggests that there's no way to filter/vpn whitelisted traffic, but this is clearly not the case, as evidenced by this article. Furthermore, it's still possible to block/filter traffic on a whole machine basis by using the Packet Tunnel Provider API.