jonah
(Jonah Aragon)
March 11, 2026, 1:16am
39
This topic remains an issue.
The completely different problem to the macOS one that Proton has on Linux, which is described at ProtonVPN IP Leakage on Linux and Workaround | PrivSec - A practical approach to Privacy and Security remains an issue (which I confirmed with testing of course).
The question here, I think, is whether this is a big enough problem to still consider Proton in violation of our current criteria, especially given that Proton specifically says to bind programs like torrent clients to the tunnel interface directly, which does solve this problem.
To be clear, the kill switch on Linux is fully functional, unless an application specifically binds to the physical network interface. This, to me, seems like an issue which would warrant using something like Qubes, if protecting access to the physical network interface is of utmost importance to you, so I’d really consider this a platform limitation of Linux more than a Proton failure. Linux being extremely permissive with what you can do with it is a double-edged sword in this regard.
I think the community is generally of two minds about this:
Thank you for your analysis. I will share the most likely counterpoint for people to consider:
I think it’s probably fair to argue that on Linux you should be aware of what you are installing and what those programs are doing. A kill switch in this scenario that applies to the default network configuration is mainly going to protect you from random disconnects, while an intentionally misconfigured program set to bypass the kill switch by binding to a specific interface could be considered out of scope for what a mere software kill switch has to be doing.
This is compounded by the fact that the way to implement a kill switch on Linux is highly variable depending on distro and network configuration, there isn’t a single system API to plug into like on Android. In some sense if you are going to be performing sensitive tasks on Linux then you need to configure them properly, and if you don’t trust yourself and/or the application you need to be using the tool for the job that prevents this problem by design , which is Qubes.
Like I said, it’s an open question I’m presenting to everyone here, and I don’t really lean towards this argument one way or the other. I think…
…is also a perfectly valid opinion to hold, and if this is what we want to say then we could still de-list Proton. I don’t think it’s unreasonable to instead simply add a warning about this edge-case either though.
It sounds to me like the consensus from this thread in December is generally that this behavior warrants a warning. What do we think?
The significance does seem unclear to me, but probably minimal. I’m leaning towards it requiring a warning, maybe in our general VPN overview since a lot of VPNs on Linux seem to require additional configuration from what I can tell. See for example: ProtonVPN IP Leakage on Linux and Workaround - #2 by anon88979181