If that’s the case, we could just add instructions to Proton’s section on how to configure something similar, even if Proton doesn’t provide a guide to do so themselves like IVPN and Mullvad do.
I am leaning towards a criteria change because I think reliance on a killswitch feature for anything more than convenience is a mistake no matter how it is implemented. Similarly to Tor Browser, we should recognize that the most robust way to completely isolate this traffic is always a VM-based solution, in Tor’s case with Whonix (in Qubes). Similarly, as the PrivSec article at ProtonVPN IP Leakage on Linux and Workaround notes, Proton’s issues are also resolved with a strong Qubes setup.
I think that anyone who will be majorly impacted by this problem should be using Qubes, and killswitch implementation quirks should be considered acceptable by non-Qubes users, although we should indeed note what they are just for their reference, but not as a “problem” with the service.
Not that I recall but this thread is pretty long and it’s been a while since it was most active, I haven’t reread it since
I don’t think leaks should happen during this. Mullvad’s lockdown mode prevents this at least. I think iVPN just uses ufw for the kill switch which also should prevent this.
iVPN requires use of the terminal, but they’re clear about that. Mullvad does not require any manual steps afaik unless you count flipping the lockdown mode toggle.
Nobody has tested them since this thread was opened but the Proton issues have existed for years so I doubt anything has changed. I don’t use Proton but if anyone wants to test it then that would be helpful.
I don’t really agree because even as an average user, I still want to minimize as much as possible how often my true IP address is exposed without me knowing. Especially the macos leak which apparently leaks every time you switch servers would render the VPN practically useless to me. But even if I set that aside, I would still personally be in favor of removing Proton because of how dishonest they have been about this (this speaks to the marketing criteria I mentioned). Mullvad is much more transparent about kill switch vulnerabilities, listing them on their website. You have to really sleuth around to find out about the issues with Proton VPN’s kill switch.
Edit: although I did just notice that iVPN does not list any vulnerabilities with its kill switch, whereas Mullvad does. Not sure if this means that iVPN’s kill switch is better or if Mullvad is just being more honest/rigorous in testing. There probably should be more investigation into this, but either way I think Proton’s leaks and dishonest marketing are much more egregious.
wow an actual response from staff and it isnt a non sequitor to become a subscriber thanks @jonah
This would be my preference.
I do think there should be some sort of warning on the VPN page saying the tool does not meet the criteria and to encourage users to join the discussion on what to do about it. Otherwise keeping Proton up there is a bit misleading.
I also think its worth looking at how VPNs are discussed as @ignoramous alludes to in a related thread.
This was my understanding - that all providers currently don’t meet the criteria as its currently constructed.
Yes from me, I don’t see any benefit in having this criterium, in fact the opposite, it could lead to excluding the best VPN for android because it’s not recommended for Windows (for example).
Mullvad on Fedora Workstation kills the daemon and does not restart it any time the Mullvad VPN package is part of an update. Before I realized this, I was using the internet with no VPN after such updates. In this scenario, the kill switch is 100% nonexistent and therefore does not work. This is a big issue IMO and should be clearly mentioned since Linux is the main desktop OS recommended by this site.
If lockdown mode is enabled this should not happen based on my understanding. I have the same setup and have not experienced this. Might be worth reaching out to support.
This happened 100% of the time while I was still on Fedora, and I always had lockdown mode enabled. Perhaps they have patched this, but I doubt it. It might just be unstable or vary depending how you update your system. It was happening every time the package updated with dnf (both online and offline upgrades). The flaw is the main reason I switched to offline upgrades.
I think this is the distinction and note I’m hoping y’all will make. Lots of beginner and intermediate folks understand the opsec systems and protections they want, but not the technical intricacies of the products. I think that’s a major function of this site. “I have x concern, so I’ll go to Privacy Guides and see if there’s a solution.”
If people need a true kill switch they need to be for the most part using TAILS, a VM solution (like Whonix), or a router level solution. (Maybe we could specify exactly this on the VPN page.) To my knowledge, most default implementations of the leading VPNs do not protect ALL traffic at the OS level. For mobile, for example, not even GrapheneOS has identified and fixed all the system level connections that travel outside the VPN tunnel. (They are working on it though.)
It’s my opinion that no VPN provider should be advertising a kill switch because I don’t think there’s a single one that protects all IP leaks for the whole OS. We don’t have control over how the VPNs advertise their products, but we have control over how we educate people about their capabilities and use.
imo, this thread’s votes & consensus seem to be for removal of recommended public VPNs that don’t meet PG’s minimum criteria right away, then figure out criteria change in a separate discussion (ex: Separate VPN Servers and VPN Clients)
If the strict criteria doesn’t make sense, then PG needs to make it explicit that VPNs don’t really help much at all with “hiding traffic from ISPs” when some traffic might in fact leak (due to imperfect client implementations or setups or both). To give an example from earlier in the thread, such leaks would be akin to a hypothetical e2ee drive app encrypting every document except ones it unilaterally deems must be kept in plaintext instead.
No, it isn’t a mistake. A “killswitch” is enforced by the OS, and without VPN apps opting in, all bets are off. As someone who develops VPN apps, “killswitch” is definitely extra work and one that VPN apps, imo, should invest in & get it right.
Wha? Why? I don’t think it is acceptable at all. Most OS-provided / OS-assisted “killswitches” (Qubes or not) prevent accidental / unintentional / intentional leaks from VPN client implementations and/or incorrect end user setups.
Should put this up on PG’s VPN page.
Changing the criteria I think needs a much bigger discussion on why PG recommends “almost always” using a public VPN.
Windows (1.5bn install base) does provide more than one way. I don’t use Windows but others may confirm.
As for “major OSes” with over 4bn active installs (iOS + Android), not true at all.
The crux is, can VPN clients provide client-side guarantees (hide traffic from ISP, from piracy orgs, etc) PG makes on their behalf? If it can’t, then that warrants a larger discussion on what else needs to be amended, including PG’s suggestion that folks should “almost certainly” use public VPNs.
Maybe? I think it is fairly straightforward to recognize that people in nearly all situations will benefit from using a VPN generally, but whether you need a killswitch, and how robust that killswitch needs to be, is more dependent on your specific threat model
The reason PG recommends always using a VPN, as I understand it, is largely to hide your traffic from your ISP and hide your IP from services/websites. If simply switching VPN servers causes your IP address to leak to all the websites and services you were using and your traffic to your ISP, then what exactly is the point of having the VPN at all? I understand that kill switches are not perfect, but I feel that this all or nothing approach is harmful.
As I understand it, information leaks in certain specific situations, such as when switching servers or connecting to a different network. But if the connection is stable and for a normal, everyday threat model, it doesn’t seem like a huge problem. I mean, all the pages you’ve visited in the last 20 minutes aren’t going to leak if, say, you switch servers or momentarily reconnect to the network. I think PG’s recommendation is still a good one.
If anyone can contradict me and argue that more information does leak, go ahead. I personally follow PG’s recommendation precisely because all I’m looking for is to protect my browsing habits from my ISP.
I’m in favour of removing ProtonVPN because PrivacyGuides is a respected authority in the privacy community, so removing the recommendation might actually give Proton the motivation to finally address this issue. If we’re not using our influence to promote more private software then what’s the point of it all?
Yes, there could be bugs in the implementation and there could be intentional leaks, too; all of which, a VPN app that is subject to & compatible with “killswitch” will prevent.
Why? All PG recommended public VPN providers are subject to similar data collection regime as the ISPs.
Did mention Windows, which does have a functional killswitch, from what I can tell (but I don’t use Windows, so I can’t test this). As do Linux-based OSes.
Are we saying it is okay for VPN clients to not be compatible with “killswitches” even when the OS provides one (which all major OSes do)? If so, where does the client-side guarantee PG claims on behalf of VPN providers for “hiding the traffic” then come from?
Note that, without “killswitch” there’s absolutely no guarantee that the VPN client itself isn’t leaking any traffic either unintentionally (due to bugs) or intentionally (compromise). Going back to e2ee Drive analogy, is PG comfortable recommending e2ee products that may miss encrypting docs due to bugs or even deliberately?
I don’t fear any court order, but rather my ISP selling my data to third parties (which it does). That’s why I trust Mullvad. It’s not far-fetched, right?
Edit: I’m responding and asking questions in order to learn, I’m not asserting anything categorically. I’m no expert, but I’m concerned about @ignoramous’s claims because if the money I’m spending on VPN and the inconveniences that come with it serve no purpose, I would simply stop subscribing to Proton/Mullvad’s services.
thanks 
