Both of you are right; just that I don’t agree that an external gateway is the only acceptable solution to on-device ‘software killswitch’ implementation limitations (in the context of public VPN providers and the threat model they operate under). For Tor, sure.
Well, any VPN provider that wants to put money where its marketing is (“hide from ISPs”) should figure this out, instead of putting the burden on the end-user.
You may know this already, but I must point out that on Linuxes and BSD-based OSes like macOS, WireGuard VPNs are (expected to be) setup exactly like this (only difference is that the “interface” is virtual not physical).
As @fiqiluvo.epileto notes, Linux supports such a setup?
The “VPN software”…
- doesn’t need to “know” if the OS provides an API to setup a ‘killswitch’.
- will have to inevitably use firewall functionality if there’s no such API (ie, it will have to “know”).
Hence the point here… What should we require of VPN providers on macOS? - #69 by jonah
Not sure why keys are relevant here? Anyhow, I must note that these keys (being sent around) are not (supposed to be) private/secret.
There’s nothing “not supposed to” here. Sockets, as the BSD APIs are, will have to bind (before connect / send) to some interface (or all interfaces)?
A “killswitch” that cannot deal with this normal / very usual scenario cannot be called a “killswitch”.
tbf, the issues you are pointing out are implementation considerations (of which there are likely to be many more than just four), not limitations.
I am not sure. Proton’s post hasn’t gone into any technical details for me to make any judgement call.
@Overall-Bet3743 pulled in an Apple engineer’s post that helped me in getting clarity on much of the speculative bits (cc: @ph00lt0 too) from the previous thread … that speculation may not have been entirely correct: What should we require of VPN providers on macOS? - #77 by Overall-Bet3743