When a new criteria is created and approved, then we can reconsider options like Proton and, see if they meet that new criteria. This has nothing to do with the current criteria though, which Proton has not met for months already.
Considering how long it can potentially take a new criteria to be approved (there isn’t even a thread suggesting an alternative right now AFAIK) it would be negligient to leave tools that do not meet the criteria up.
Just look at the uphill climb users have faced trying to get open source to be a requirment for Password Managers as an example of how drawn out a criteria change can be. Thats after @jonah defined what open source is for everyone, which I suspect he might have to do for “kill switch” considering past replys.
They are aware of this issue and also aware of this thread. They are even in this forum. They were on here a couple days ago to give a boilerplate response to another issue (that for the record they aren’t at fault for). Please stop lobbying so hard in defense of the privacy company that has more resources at their disposal than any other privacy company and still chooses to release and maintain faulty products. You can search the forum, this VPN issue is not the only glaring flaw in their products.
EDIT: @Proton_Team (Y’all have already been tagged in this thread though, so this is just a symbolic tag to please @banana.)
Optimally designed for every platform as could be expected of the biggest privacy company on the planet != perfect and can never leak ever.
Besides, this is the Proton thread. If you think Mullvad VPN has known leak issues that they can fix if they put some effort into it, go create your own threads about that. “But the other VPNs!!” isn’t an argument for keeping a subpar client on the list.
I’m sorry, but that is precisely what was being discussed by @jonah and @ignoramous. If no VPN actually meets that criterion, then we need to:
Remove Proton since it is not on the same level as the other providers (on MacOS/Linux).
Remove all VPNs because none of them meet one of the criteria (kill switch).
Keep all 3 providers (Mullvad, iVPN, and Proton) and add notes on which platforms their kill switches fail and under what circumstances. After all, ProtonVPN is the only one that can be used for free.
We are simply making arguments here. It just seems to me that saying it “does not meet the criterion” is being dishonest, because you would not be willing to remove the rest of its competitors. The issue was already raised regarding the other VPNs (see Remove iVPN).
The question is: are you willing to also remove Mullvad and iVPN if Proton is removed?
Why? Proton has known bugs/lazy implementations of their kill switch. Mullvad and IVPN do not. Theirs actually work as intended on MacOS.
Why remove the ones that actually put the effort in? On iOS/Android leaks are to be expected due to how those platforms work. On MacOS it’s possible to make a functioning kill switch that doesn’t leak when.. switching servers.
In what way do you consider Mullvad to have a flawed kill switch?
The issue is there isn’t an option that agrees with my viewpoint, which is that it be removed until it meets the minimum criteria established for VPNs to be recommended by PG.
TLDR: They have located much of the info Android allows to be sent outside of the VPN tunnel. They are aware there are still more of these instances that need to be fixed.
GrapheneOS greatly improves Android’s protection against VPN leaks for both the built-in VPN support and VPN apps with the standard “Block connections without VPN” toggle enabled.
Android allows DNS queries from the system resolver to leak to the network provided DNS servers when a VPN app goes down due to a race condition. It also similarly allows connections to the VPN DNS servers to happen outside of the VPN tunnel. Both of these are fully prevented by GrapheneOS through extending the leak blocking to this part of the system resolver, fully preventing unicast DNS leaks.
Android allows processes including apps to bypass the VPN entirely whether it’s up or down by sending multicast packets either directly or by causing the kernel to send the packets on their behalf through the standard multicast group management system calls. GrapheneOS extends Android’s standard eBPF filtering with full support for blocking all forms of multicast packet bypasses. We also disallow using the system Network Service Discovery Manager for connecting to mDNS-based services when VPN lockdown is enabled.
Android VPN configuration is split up for each profile which means work profiles, Private Spaces and secondary users have their own VPN configuration which is a fantastic privacy feature. Android has a standard restriction preventing processes from using a network which the current profile isn’t allowed to access. However, this doesn’t take multicast packets into account and it’s possible to send multicast packets via VPN tunnels belonging to a different profile. GrapheneOS addresses this by extending the standard netfilter configuration with a multicast firewall preventing sending packets through a VPN tunnel which a process isn’t supposed to be able to access.
GrapheneOS closes a hole in Android’s eBPF-based firewall system which made it possible to bypass the VPN by specifying a specific interface with a special system call.
Finding and resolving all forms of VPN leaks is one of our top priorities at the moment and we don’t currently consider this to be a complete feature due to less severe additional issues we’ve discovered.”
Android: probably, but no documentation from iVPN or external research (or at least I couldn’t find any).
MacOS: undocumented but likely.
Windows: same as Mullvad.
Mullvad is the most honest VPN out there. But notice that the only argument you have left is that “Proton leaks the IP when switching servers.” It’s not that Proton fails to meet PG’s criteria, but rather that you choose (in my opinion, more or less arbitrarily) that it’s unacceptable for Proton to leak in that specific scenario, while the leaks from other providers simply don’t matter.
Why not add a warning that this leak occurs on MacOS when switching servers? Just as with the leaks that can occur on other operating systems, and expand the warnings accordingly. Or simply remove PG’s recommendation to use a VPN altogether.
In my opinion, what you’re trying to achieve by removing Proton from the recommended list is to “punish” the company for a number of other reasons: poor management and development, the lack of a Linux client for Drive, the inability to purchase subscriptions separately, the way they are diversifying their products, etc.
It’s not arbitrary. It’s because Proton’s leaks are preventable. The others you mention require changes to the OS that VPN clients can’t control. Not sure why this is so hard to understand.
Arbitrary is the decision to consider that flaw as essential, when there is no mention in the PG criteria of a ‘hierarchy’ of flaws or anything of the sort.
Sure, but I think most here are also advocating for changes to the criteria to excuse leaks caused by OS level limitations.
Personally I find it upsetting that the page implies that any VPN has a functioning kill switch without any caveats, and that it has remained that way for months at this point, continuing to mislead people. But at least mullvad and ivpn seem to do a better job at communicating and disclosing what their services can and can’t do, and seem to fix what they can.
Honestly if the PG team doesn’t have the bandwidth to quickly tackle this in a graceful way and wants to just nuke the VPN page temporarily, and say it’s being redone or cover it up with a warning that there are many significant VPN leaks and we’re trying to figure out what to do, linking to this thread, I think that would also be reasonable. The main problem is that nothing has been done at this point and site visitors continue to be actively misinformed every day that this goes on. And to make matters worse there is barely even any engagement from the team in this thread, so we have no idea what they’re even thinking.
I agree. It would be much better to remove ProtonVPN first and then take the time to determine whether the criterion need to be changed, instead of remaining in this state of limbo.