Remove ProtonVPN

[anonymous549]

@nicotiu

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

This seems like you are establishing a new criteria. You’re shifting from the more clear standard of a “working killswitch for all major operating systems” to a more vague notion of being “stable and suitable for a normal, everyday threat model.” This could imply that functions that are only partially effective, like the killswitch, are still seen as reliable. Terms like “normal” can be quite ambiguous, making it challenging to determine what the baseline expectations should be.

---

@Alvah.Lind64

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

Yeah, its unclear to me why this suggestion isn’t marked approved yet or why Proton has not been removed yet, since we all seemingly acknowledge it does not meet the criteria.

I understand it might not be the end goal resut we want but, currently it seems to be clear cut Proton should be removed until a new criteria is created and approved.

---

@jonah

I disagree, if it’s reasonable to think it’s most likely that we’ll change our criteria, then we should do that.

Given its taken multiple weeks just to get anyone with decision making authority to respond to this thread and, given how long tool suggestions and criteria posts take to get approved this seems unreasonable.

Removing tools that do not meet the current criteria, regardless of what people might think the possible new criteria will be, is a much more honest way to operate. Especially since PG is not warning its users when tools are not meeting the critera in any sort of reasonable timeline.

[nicotiu]

@anonymous549

The seems like you are establishing a new criteria.

I’m not stating anything. The comment above said:

@Anvil

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?

And I simply commented that I believe not all the pages you’ve visited are revealed, but only those you’re trying to access while switching servers, etc.

I’m not defending Proton, I’m saying that @Anvil’s comment seems exaggerated to me. The recommendation I’m referring to is the following:

@ignoramous

including PG’s suggestion that folks should “almost certainly” use public VPNs.

Not the one about using Proton. I think you should read the entire thread.

[anonymous549]

@nicotiu

And I simply commented that I believe not all the pages you’ve visited are revealed, but only those you’re trying to access while switching servers, etc.

I am a bit confused… This comment is really only summing up the first sentence of your response and now your saying you didn’t say the rest of your response?

[anonymous544]

Kill switches are absolutely necessary for VPNs.

[nicotiu]

But which Killswitches work perfectly on Android and MacOS? Because as far as I understand it’s more a matter of the OS than of Mullvad, Proton, etc. That’s why the whole question of the general usefulness of using VPNs with killswitches was opened up. Is there any provider that doesn’t leak the IP under any circumstance on these OS’s?

[Expert4870]

Monero

Additionally, proton is the only one recommended without Monero support. I don’t think that they are a serious privacy VPN without accepting convenient private payments. I know this is only part of the best case criteria, but there are so many VPNs today that accept Monero, I don’t really see what Proton is playing at.

[dadnerd]

Proton has issues in addition to the OS level issues. They know about the issues and do not patch them, just like they know about bugs and flaws in many of their products and do not patch them. It’s sad to say, because I’ve been a fan of Proton literally since they launched, but at this point in their evolution they care only about user growth. With the resources available to them, their products should be essentially flawless from a privacy and security standpoint, and yet they’re far from that. I began moving to alternate products about a year ago. The only time I use Proton VPN is when I need a VPN that doesn’t need an account.

EDIT: I believe Proton is still an excellent choice for people starting their privacy journey, but recommendations need to come with the proper disclaimers.

@ignoramous

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.

For Linux, are you referring to setting up a VPN using Wireguard? I’m not aware that Linux has an OS level kill switch, and I’m not aware that any OS has a kill switch that enforces sending literally all traffic through the VPN tunnel. Android certainly does not do this. I think it’s possible Wireguard on Linux does this, and I still wouldn’t trust it for any threat model more critical than surveillance capitalism. If you need an actual kill switch that is almost certain to not leak your IP unless compromised, it needs to be done via a VM (Whonix, Qubes) or at the router level.

[nicotiu]

@dadnerd

I’m not aware that any OS has a kill switch that enforces sending literally all traffic through the VPN tunnel. Android certainly does not do this. I think it’s possible Wireguard on Linux does this, and I still wouldn’t trust it for any threat model more critical than surveillance capitalism. If you need an actual kill switch that is almost certain to not leak your IP unless compromised, it needs to be done via a VM (Whonix, Qubes) or at the router level.

Exactly (thanks!), this is what’s being discussed based on Jonah’s messages above. I was defending the general use of VPNs (with a kill switch), not Proton specifically. The conversation was reaching a point where the use of VPNs with a kill switch was being delegitimized, but I think either my comments were taken out of context for some reason, or I didn’t explain myself clearly.

[ignoramous]

@nicotiu

But which Killswitches work perfectly on Android and MacOS?

There’s a separate discussion on this: Mention kill switch leaks caused by OS limitations - #4 by ignoramous

@nicotiu

Is there any provider that doesn’t leak the IP under any circumstance on these OS’s?

In the “shared responsibility” model that most OSes operate in, the VPN provider’s responsibility is to make sure its clients are compatible with OS-provided or makes use of OS-assisted “killswitches”. Whether an OS itself “leaks traffic” despite the “killswitch” is not a problem the client can solve.

To give you an analogy, if an OS provides a “keystore” for an encrypted notetaking app to securely store its secret keys, it is prudent to demand that the app use it. Whether the OS’ “keystore” is backed by a tamper-resistant hardware security module (HSM) or not is secondary. A considerate notetaking app will however caution its user about the missing HSM.

money I’m spending on VPN and the inconveniences that come with it serve no purpose

@nicotiu

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.

If your ISP told you that they sell information about you, then using a proxy makes sense.

ISPs may however extract browsing profile from IPs you visit & from DPI (deep packet inspection), if need be even if one uses encrypted DNS; but there’s costs associated with DPI; especially with the ungodly amount of traffic that flow through larger ISPs. ISPs usually collect “flow logs”, from what I know, only in compliance of government mandates … which, VPNs might also be subject to as the EU e-Evidence Regulation notes above.

Some argue VPNs provide KYC-less accounts & payments; but when your devices connect to the public VPN provider’s servers, your IP is exposed to them anyway (an IP provided to you by your ISP who has done its KYC); so there’s not really that much to rely on & probably the reason why PG recommends Tor + Quebes / Whonix for those usecases. That said, this a discussion for a different thread.

---

@dadnerd

I’m not aware that Linux has an OS level kill switch, and I’m not aware that any OS has a kill switch that enforces sending literally all traffic through the VPN tunnel.

Are you referring to a single “switch” that can be flipped on and off? If not, Linux-based OSes should let users control if all Internet-bound must flow through a VPN tunnel or be dropped, if not.

@dadnerd

If you need an actual kill switch that is almost certain to not leak your IP unless compromised, it needs to be done via a VM (Whonix, Qubes) or at the router level.

And what’s guaranteeing that the guest VM will not leak? It is the host. But you’re just now arguing that hosts like Linux do not provide “killswitches”…

@dadnerd

Android certainly does not do this.

Depends on the Android flavour. GrapheneOS, for instance, tries very hard to not “leak”, but Android has a security model in which privileged components are well… privileged. In that model, no unprivileged app (all user installed apps) are supposed to be able to “leak traffic” outside the VPN when Android’s “killswitch” (called the “VPN Lockdown mode”) is turned on. The catch with Android is though, the VPN apps must be compatible with the “killswitch” (ex: recently, hardening the ‘VPN Lockdown mode’ made a few popular public VPN provider apps non-functional on GrapheneOS).

[dadnerd]

@ignoramous

And what’s guaranteeing that the guest VM will not leak?

Whonix and Qubes are specifically designed to have actual kill switches as far as I’m aware. The Whonix Workstation will only connect to internet through the Gateway, which must be running TOR. Whonix - Superior Internet Privacy

Qubes has potential for complete process isolation.

(Conversely, just running a Fedora VM that has access to your network would not provide a true kill switch.)

[ignoramous]

@dadnerd

Whonix and Qubes are specifically designed to have actual kill switches as far as I’m aware.

From what I can tell, they are designed to make sure the OS is setup to provide anonymity. A “killswitch” is a necessary but not a sufficient condition for that.

@dadnerd

The Whonix Workstation will only connect to internet through the Gateway, which must be running TOR. Whonix - Superior Internet Privacy

This is getting offtopic for the current thread… but if one is running Whonix / Qubes as a guest… then what’s in the control of the “gateway”, the host or the guest which is running Whonix / Qubes? Whonix documentation notes that physical isolation (ex) of the “gateway” is required to defeat VM exploits (ref).

@dadnerd

true kill switch

What’s a “false” killswitch? Or, you mean, Fedora has a “false” killswitch but Whonix has the “true” one?

[dadnerd]

@ignoramous

What’s a “false” killswitch?

The way killswitch is marketed by both OSes and VPN providers leads people to believe that their IP will only ever be known to the VPN provider. This is false. I am not aware of any OS or VPN that honors this. Someone other than the VPN provider will be able to know your true IP address in almost all OS/VPN configurations I’m aware of. For example, GrapheneOS is making progress on this, but there is still traffic that travels outside the tunnel even with their significant hardening.

The only point I’m making, and the only point I care about is Privacy Guides should state this very clearly on the VPN page. VPNs are a great idea, and they also are not suitable for any threat model aside from censorship circumvention or surveillance capitalism. PG’s recommendations state some of this, but not all of it, and it’s not stated clearly enough.

[HackOrSwim]

@dadnerd

Proton has issues in addition to the OS level issues. They know about the issues and do not patch them, just like they know about bugs and flaws in many of their products and do not patch them.

Can you give some concrete examples?

I do share some of your disappointment with how slow they add new features and fix issues on some of their products and the lack of feature parity across platforms, but I wouldn’t say they only care about user growth. In the past couple of months, they seem to be migrating their products to a “shared base, independent frontend” architecture, which has made things like the mobile Proton Mail app have feature parity. This model was first used, AFAIK, on Proton Pass. They are also working on the Drive SDK to (hopefully) make development of new features easier. All this to say, I think they are definitely trying to improve, but issues like the lack of a proper killswitch on all platforms absolutely should get light shed on them and some attention from the devs.

[dadnerd]

I’m not trying to be dismissive, but there are ample documentation of the flaws in their products in other threads as well as on github. That is very off topic for this particular thread.

[ignoramous]

@dadnerd

The way killswitch is marketed by both OSes and VPN providers leads people to believe that their IP will only ever be known to the VPN provider. This is false.

The way VPN clients are marketed; not the “killswitch” itself.

Security is usually a shared responsibility. If there’s a “killswitch” then a client is better off using it, because if it doesn’t, all bets are off. The traffic may then leak not just because of the OS’ shortcomings but also because of the VPN client’s. The latter is in the control of the VPN provider, the former is not.

For example, VM & sandbox escapes do exist (due to bugs in the implementation or bugs in the OS/Kernel); but that doesn’t mean projects like Whonix/Chrome put the towel in and abandon isolation/sandboxing. Those projects must continue to use the tools made available to them by the OSes and sandbox/isolate to the extent feasible. Without them doing that, all bets are off.

@dadnerd

I am not aware of any OS or VPN that honors this.

You just said Whonix does? I am not sure what your stance really is.

@dadnerd

Someone other than the VPN provider will be able to know your true IP address in almost all OS/VPN configurations I’m aware of … The only point I’m making, and the only point I care about is Privacy Guides should state this very clearly on the VPN page

Like mentioned above, this is offtopic for this thread. Do consider contributing here: Mention kill switch leaks caused by OS limitations

[dada_goose]

I agree with those saying Proton should be removed. If the kill switch doesn’t work as advertised, doesn’t meet the criteria and there are other VPNs which can make it work, why put it on the same pedastal. Removing might be a good incentive for the company to make the necessary changes. I say this as a user of other Proton apps and huge fan of what Proton do.

[lyricism]

@jonah

I am getting this overall impression from most people on this thread, does that seem accurate to everyone?

Respectfully, I don’t know where you get that impression from. Based on the votes and comments overwhelmingly those participating in the thread seem to be in favor of removal.

@jonah

It seems more likely to me that the strict criteria no longer makes sense.

But like, why though? Because enforcing it would require removing ProtonVPN and you’re afraid to do that because you think removing the largest respected privacy company’s product could harm the site reputationally or otherwise? I have enough faith in the team here to know that there’s probably not anything financial at play, and therefore I can’t really see why else the criteria “no longer makes sense” considering other providers don’t have a problem meeting them.

@jonah

I disagree, if it’s reasonable to think it’s most likely that we’ll change our criteria, then we should do that.

I do agree with this, depending on timeline. There’s no point removing a recommendation if it looks like the criteria will be changed e.g. next week and they’ll be able to be added back again after. However, this was raised months ago and the criteria are still in place. I don’t think it’s reasonable to leave a recommendation in place for months while the community debates a criteria change without even knowing the outcome of that debate yet.

@jonah

I think reliance on a killswitch feature for anything more than convenience is a mistake

This take is, at best, extremely hot, IMO, and I think there needs to be further discussion around it before any changes are made on the back of it.

@jonah

I think that anyone who will be majorly impacted by this problem should be using Qubes

I think it’s kind of wild to suggest that you either need to use Qubes or you don’t need a kill switch to the point I am questioning if that was suggested in bad faith. Obviously there is a use case for a VPN killswitch without using Qubes and “use Qubes” is not really an answer for people who are only asking for a functional killswitch on their existing OS.

@jonah

killswitches are generally not OS-provided or OS-assisted on major desktop platforms

This might be semantics, but it’s impossible to implement a non-OS-assisted kill switch, considering the OS provides the network stack.

[HelloClippy]

I think it’s kind of wild to suggest that you either need to use Qubes or you don’t need a kill switch to the point I am questioning if that was suggested in bad faith. Obviously there is a use case for a VPN killswitch without using Qubes and “use Qubes” is not really an answer for people who are only asking for a functional killswitch on their existing OS.

Also, running a VM is resource-intensive, so Qubes OS is not a viable option for most users, especially given the current high cost of RAM and other resources.

[Ganther]

Indeed, that’s a great point. Removing Proton VPN could actually make them fix the issues. And at this point I’m surprised it’s not been removed already. If it’s not up to the standards then why is it on the site at all?

The argument being made by some here that a kill switch is largely meaningless is choco bananas to me.

Should the user really expect a VPN to leak and potentially be useless if not using Qubes OS and GrapheneOS? If so, why even have a VPN section at all? It could be subsections for those two if that’s the way we want to go.

[Encounter5729]

@Proton_Team it would be really useful if you answered this thread.

I think most here (including those who want the removal) would accept keeping the app if you commit to fixing leakage issue. Including at least the Linux IP leakage issue, which there is no* valid excuse for.

I will probably continue to use Proton VPN, but I don’t think we should continue recommending it anymore. That is because the broader concern is underinvestment in PVPN, which worries me about the security of the whole architecture. The Linux app is very buggy, and I often have to use the taskbar tray to connect to a server instead of in the app.

*I suppose there could be some use for advanced users. But in that case, make it a choice, not the default.