Change Proposal on Privacy Guides Recommended VPN Providers Page

[anon82422799]

Greetings-

I would like to propose an idea for a potential change to be made regarding the recommended VPN providers section or page on the official Privacy Guides website.

Proposal-

In light of the discussion thread regarding the community proposal to completely remove ProtonVPN from the Privacy Guides VPN recommendations page, I would like to propose an alternative idea suggested by privacy.slouchy to amend the VPN section of Privacy Guides for separating out recommended VPN providers and make a dedicated section for VPN clients.

As written by @privacy.slouchy in the Remove ProtonVPN thread:

Maybe PG should split the VPN recommendation category into two more specific silos

VPN Service Providers: reliable, privacy-centric server networks. Wireguard support, multi-hop, etc. Proton continues to excel here

VPN client software: the actual application users run to send traffic through a VPN tunnel. Reliable kill switch, open source, cross-platform (maybe) etc. The aforementioned issue with ProtonVPN’s kill switch falls under here

PG currently groups them together under a singular VPN recommendation page, presumably bc most trusted VPN service providers also provide a VPN client. But one could make the argument that these are two very different products, and should be evaluated independently

Reasoning-

I believe that this idea proposal will be a successful middle ground solution that satisfies the desires of those who believe that ProtonVPN should be removed for failing to meet the current PG criteria of having a working VPN kill switch on all of their clients across OS platforms, while also meeting the wishes of those that want ProtonVPN to stay recommended on Privacy Guides as a provider due to the long-time reputation and viability that they still have in the general privacy community. Therefore, this should theoretically settle the ongoing conversation in the ProtonVPN removal proposal that satisfies the wishes of both groups while also improving the recommendations given by Privacy Guides as a whole in the VPN section.

I hope that the Privacy Guides team/staff will take the time to give this proposal some serious and thoughtful consideration.

Thanks!

[JG]

For anyone reading, this is the criteria PG has right now. Quick link for the lazy:

Private VPN Service Recommendations and Comparison, No Sponsors or Ads -...

[JG]

I do see a reason for some change in the criteria but I don’t see it necessarily being it done this way. This is fragmentation and a non unified view on what PG thinks of VPNs and will only lead to confusion among the average person who is simply looking for a well researched answer for the VPN to use (and not evaluate the product themselves to learn of the differences and why which this will lead to).

Let’s break it down -

Minimum:

1. Support for strong protocols such as WireGuard.

   1. Excellent. This should stay the same.

2. Kill switch built in to clients

   1. define clients and explain if only kill switch should exist or also work as intended (which means they would need to be tested by PG to determine its operation).
   2. Should the VPN provider provide support for all clients/computers (Windows, Mac, Linux, iOS, Android) with this feature that works in order to be considered for recommendation.
   3. I’d rather they change “client” to simply be called “VPN app”. Its easier for the average person to understand because even the WireGuard app is technically a VPN client. Why have anything that leads to more follow up questions?

3. Multi-hop support. Multi-hopping is important to keep data private in case of a single node compromise.

   1. This is okay. No change needed here.

4. If VPN clients are provided, they should be open source, like the VPN software they generally have built into them. We believe that source code availability provides greater transparency about what the program is actually doing.

   1. No complaints here except I do believe VPN apps and services should be externally audited with publicly released reports. In today’s day and age, this should be the bare minimum too.

5. Censorship resistance features designed to bypass firewalls without DPI.

   1. No complaints here either.

Best Cases:

1. Kill switch with highly configurable options (enable/disable on certain networks, on boot, etc.)
   1. If they work as intended (upon testing), then yes - this should continue to be here.
2. Easy-to-use VPN clients.
   1. What does this mean exactly? It’s vague and leads to follow up questions. I think there needs to be tangible guidelines for what qualifies as a VPN app being easy to use if you’re going to keep having this. In my view, we can do away with this. Every app is going to be easy enough to use. This adds no value.
3. IPv6 support. We expect that servers will allow incoming connections via IPv6 and allow you to access services hosted on IPv6 addresses.
   1. No issues here. This should remain the same.
4. Capability of remote port forwarding assists in creating connections when using P2P (Peer-to-Peer) file sharing software or hosting a server (e.g., Mumble).
   1. In my view, this should not be necessary but is of course nice to have. I can live with or without this as a best case requirement. Even doing away with this would be okay. A VPNs’ primary use case is still being met as best as possible even if port forwarding is not available which to be does its job as intended.
5. Obfuscation technology which camouflages the true nature of internet traffic, designed to circumvent advanced internet censorship methods like DPI.
   1. Should remain the same. No change necessary albeit the world is changing fast where actual obfuscation may become important if not absolutely necessary because if countries can’t block VPN services/apps, they sure as hell will (try to) begin blocking the WireGuard protocol from functioning. Something to be aware and mindful of is all.

–

I have no other issues at large with how Privacy Guides recommends VPNs. Other criterion’s seem alright.

I think one of the tenets PG should follow is to always express and explain things unambiguously and such that there are no (obvious) follow up questions from any exposition and recommendations. Everything should be properly explained. As of right now, the way I am reading it as if I were that average person, you can see how some things are ambiguous if not questionable.

What PG should decide on is if a VPN service/app should work on all devices as the feature set would lead you to believe before they are even considered for recommendation here. or should there be notes and exceptions for select OSs and whatnot. In the end, I think it’s coming down to this (cohesiveness, uniformity, and consistency).

I have nothing more to say on the matter but thought I’d give my two cents properly explained. I hope PG heeds to asks of the forum members for how they can better their work on the website.

[ancientlake]

I do not see why we would implement this elaborate solution in order to continue recommending a service that continually misleads users about how their features work AND does not meet pg’s own minimum requirements. Baffling to me that proton continues to be viewed with trust. Anyone who has a high threat model should just use services from providers that do not repeatedly misstate their capabilities. Notes should be added to ALL services that do not work universally and reliably as they are advertised. This should not be hard for pg to do, and I’m pretty confused why it’s not already done for the VPNs. This is truly a great site and great community, but flaws in the recommendations seriously undermines credibility and puts users at risk…potentially seriousy risk.

[Novelrom]

I think I would prefer we just drop protonVPN over changing the current minimum requirements to make it more fragmented. Having read the other thread and as someone who uses ProtonVPN regularly - its fine, but not as technically competitive when compared to more explicitly vpn focused providers like Mullvad and IVPN.

Will I stop using Proton if the rec is dropped? Probably not, but I do agree its functionality is limited on other platforms especially when it comes to the kill switch and thus does not match the current requirements.

That being said, Im not against refining the criteria, but imo leaving the kill switch requirement for all platforms makes sense to me if you say our vpn has a kill switch. If you have to use cli to enforce it on some platforms, that makes it difficult to recommend since the answer will be well it depends.

We should want platforms to match the needs of their people that use it rather than trying to create caveats. ProtonVPN is fine for me and I think overall good, but needs further improvement.

[anon82422799]

@ancientlake

Baffling to me that proton continues to be viewed with trust.

1. Proton is one of the biggest names out there for companies that provide privacy-focused solutions for the average person.

2. Besides the kill switch issues that were pointed out, Proton has yet to do anything seriously damaging to their reputation that would change the general consensus around them in the privacy community.

3. ProtonVPN is among the few trustworthy and recommended VPN options that still supports P2P/Port Forwarding, and geo-restriction unblocking for streaming services. It is made with general usage in mind, not for strict privacy at all costs use cases like what iVPN and Mullvad are made for, neither of which supports streaming unblocking or port forwarding anymore.

@ancientlake

Notes should be added to ALL services that do not work universally and reliably as they are advertised. This should not be hard for pg to do, and I’m pretty confused why it’s not already done for the VPNs.

…Hence why this proposal is being made. With JG’s suggested amendments that he laid out as well in addition to the proposal, this aims to solve the exact problem that you pointed out.

@ancientlake

Anyone who has a high threat model should just use services from providers that do not repeatedly misstate their capabilities.

…Then go ahead and use Mullvad or iVPN. Those are why both of those VPNs are recommended as well. I don’t think anyone has claimed that ProtonVPN is aimed towards those who want maximum privacy.

[privacy.slouchy]

Trusted VPN networks that do not log activity are few and far between. Altogether abandoning one of the few services that can keep high-risk users safe on the grounds of a faulty client is foolish imo. I have not yet seen any evidence to suggest the ProtonVPN service itself is anything less than highly trusted

I fully endorse modifying the recommendation criteria to continue recommending the ProtonVPN server network in some way that does not also put high-risk users in danger by pushing client software that may have faults

[phnx]

This is not a good idea. You would lose many of the security and privacy benefits offered by first-party clients like post-quantum tunnels, DAITA, etc.

[ancientlake]

@anon82422799

Besides the kill switch issues that were pointed out, Proton has yet to do anything seriously damaging to their reputation that would change the general consensus around them in the privacy community.

I haven’t kept a list of all the flaws in the proton capabilities in the last 8 years I’ve used it, but it’s been multiple times where I learned that their service did not work as advertised.

Currently, I’m dealing with their proton pass linux client that DOES NOT AUTO LOCK itself. Guess what? Proton still advertises that it locks, and the app itself still has a setting to enable auto lock. I contacted customer service and they told me the devs intentionally changed the feature so that the app auto locks ONLY when you close the window or minimize it to tray. That is not auto lock, and it puts people at risk of thinking the feature works when it does not. This was an intentional change by proton and I’ve confirmed that with two separate customer service reps. This does not sound like behavior that a reputable privacy company would engage in. I’m leaving it at that, because this is now off topic.

[JG]

To add to my own comment, I should mention that @ignoramous has had many good points on many other posts on several occasions. If PG truly does crowdsourcing and is serious about taking input from experts in the community, it would behoove you to listen and evaluate holistically and not just pretend to because your favorite tool/product is at risk of de-listing.

I forgot to add this in my comment as it just came to mind. I adore Proton too but if something doesn’t work as they say it does, at-least an explicit note is to be added if it only works on select OSs. Or amend the criteria altogether and recommend accordingly.

Do something at least.

[anon82422799]

Essentially, one of the main premises of this proposal is to decouple the VPN client recommendations from the recommendations of the VPN providers themselves. In this way, PG could theoretically keep ProtonVPN as one of the main top recommendations as a VPN provider, but not recommend the use of their first-party clients and instead encourage using ProtonVPN with a third-party one that has a proper kill switch feature if that is something that a person looking would truly want. That is the main idea. For Mullvad and iVPN, the use of their first-party VPN clients can still be recommended and encouraged for use to get all of the features that you mentioned were important.

[anon82422799]

@JG

If PG truly does crowdsourcing and is serious about taking input from experts in the community, it would behoove you to listen and evaluate holistically and not just pretend to because your favorite tool/product is at risk of de-listing.

As much as I do like Proton, I am in the same boat. If PG ultimately decides that the best fit is to indeed remove the ProtonVPN recommendation altogether, I won’t be sore or upset about it, or anything like that. This was just an idea of an alternative that I thought would be good.

[JG]

@anon82422799

one of the main premises of this proposal is to decouple the VPN client recommendations from the recommendations of the VPN providers themselves

That doesn’t serve the purpose because almost everyone is still going to use the GUI/app/client and not with WireGuard directly. Plus, you lose the “features” and other functionality of the app itself that is almost always useful including selecting obfuscation options if you need to if you live in a censorship heavy country (which more of the world is starting to as the West collapses in this regard)

@anon82422799

That is the main idea.

I get your point but it’s not resolving the issues at hand though.

[JG]

@anon82422799

I won’t be sore or upset about it, or anything like that.

It would still be an excellent VPN but also would unambiguously signal Proton to get their shit together on this one at-least.

As far as I know, the issue is on macOS and desktop Linux. PG criteria should also go harder. Unless you have feature parity across desktop OSs, you don’t get recommended or even considered for it. Only way to “force” companies to not continue to disparage desktop Linux users. (as good of a reason they may have, still not excusable anymore going into 2026 with how horrible Windows has become).

Mullvad clearly would keep winning and so would IVPN too I think though I can’t confirm this as its been years since I used IVPN on Linux. Perhaps someone can confirm this on Fedora at-least.

[privacy.slouchy]

off topic

@JG

Unless you have feature parity across desktop OSs, you don’t get recommended or even considered for it. Only way to “force” companies to not continue to disparage desktop Linux users

This is the strongest argument Ive seen on PG for cross-platform support as recommendation criteria

[JG]

I’ll take that as a compliment.

But the community is still split and fragmented with how I and others who may agree with me are thinking, how OP and you may be thinking, and how PG team and fans of the current criteria may be thinking.

There’s still no consensus for the most part. The way forward is to take in each person’s views/comments as objectively as you can and impartially weigh them against proposed changes. I think one thing almost everyone can agree is that some changes need to be made. How is the equally large if not larger question.

Even if all that notwithstanding, all I can say is this has certainly divided the community on what should be done and how.

[ignoramous]

@privacy.slouchy

Trusted VPN networks that do not log activity are few and far between. Altogether abandoning one of the few services that can keep high-risk users safe on the grounds of a faulty client is foolish imo.

Even more detrimental to believe PG recommended VPNs are no logs / no monitoring^[1][2] / no backdoor;^[3] these remain pinky promises (PG’s knowledge base notes this). No popular public VPN provider guarantees this, as of today. Whereas, a few niche ones may do to varying degrees.

From Proton’s rather honest infrastructure audit report from 2024 (no shortage of audit reports that read like a marketing brochure):^[4]

"There is an additional accounting service whose goal is to prevent abuses and ensure the continuity of the Proton VPN. Its actions are performed by a dedicated external system, owned, and managed solely by Proton Team. These servers are kept in a secure location in Switzerland. User data is not logged or stored there in redundant, unnecessary amount. The accounting service was outside the scope of the audit.” securitums-security-report-for-proton-vpns-no-logs-policy-2024 : SECURITUM : Free Download, Borrow, and Streaming : Internet Archive

Discussion: What's the purpose of paying a VPN provider anonymously? - #4 by ignoramous

---

1. “However, the Swedish police authority may have access to information by way of coercive measures such as seizure and search of premises.” … “According to Swedish law, a police authority may request access to personal data through a coercive measure in criminal procedures … Examples of these types of coercive measures may be secret interception of electronic communications, secret electronic communications monitoring, secret camera surveillance, retention of mail and secret room interception.” Swedish legislation relevant to us as a VPN provider ↩︎

2. Yet another pinky promise: “DSA regulates online intermediaries and platforms such as marketplaces, social networks, content-sharing platforms and app stores. Its main goal is to prevent illegal and harmful activities online and the spread of disinformation. Mullvad, in its capacity as a provider of VPN services, is subject to certain provisions of the DSA but is not imposed with any monitoring obligation. Instead, it is stipulated by the DSA that Mullvad, for instance, should provide transparent terms and contact information. Mullvad asserts that it fulfils the requirements of the DSA.” Swedish legislation relevant to us as a VPN provider ↩︎

3. kfreds, co-founder at Mullvad AB: “Regarding backdooring websites, that’s interesting. I’ll have to ask someone about that. Thanks.” … “Having said all of this, I am concerned about National Security Letters and similar concepts. Technologies like reproducible builds, transparency logs, and remote attestation can help there.” … “Physical security is hard. However, I see no reason to limit ourselves to only software-based mitigations.” > *Here I'd say look at the jurisdictions of the orgs.* Per *Covert Surveillance... | Hacker News ↩︎

4. See if you spot the clever word salad about ‘logs’ but not in an ‘unnecessary amount’. ↩︎

[lyricism]

(I am writing my response to this divorced from the context of the ProtonVPN removal thread)

This seems well-intentioned but unnecessarily confusing for newcomers. People might not realize they need to refer to a separate page to learn if they should be using their VPN providers first-party app or the standard Wireguard client.

If we wanted to make a separation here, it seems better to keep them integrated within the VPN provider recommendations, but have a special additional criteria for a first-party VPN client on a given platform, and have a kind of table for each provider indicating which platforms their first-party clients are recommended to be used on, if any.

But even that seems a bit overly complex, and recommending the Wireguard client instead seems like a weird compromise since it seems likely even a lacking first party client would still have more benefits over it. I think any VPN provider worth recommending should be able to keep feature parity across platforms for their first party clients to meet the minimum requirements.

[gapless]

Maybe it’s my bias^[1] showing, but this would feel like PG bending over backwards just to keep ProtonVPN in its list of recommended providers. If anything, I think PG needs to tighten its tolerances with regards to VPN providers, especially with regards to their deficiencies^[2] on different platforms.

I do think a section dedicated to the various tunnelling (WireGuard, Amnezia, Shadowsocks, V2Ray, etc) clients would be helpful, but the motivation behind it should not be the VPN provider(s), but the platforms the said clients are made for instead.

---

1. I avoid them mostly because of the cringey saviour syndrome exhibited in their marketing material (mainly their blog), not for any technical reason. ↩︎

2. If reddit is to be believed, Mullvad’s split-tunnelling is somewhat broken on macOS. ↩︎

[anon82422799]

Greetings all-

I have read the additional comments here, and I really appreciate everyone for reading and taking the time to express their thoughts and perspectives on this proposal. I see that some of the main concerns about this being expressed are the impact of this on the approachability for newcomers that are not technically inclined, feature parity across operating systems, and the general reality of VPN trusts and claims. I can definitely see and understand the reasonings behind the opposition.

However, one thing that I would like to provide clarity on and emphasize is that this proposal is neither specifically centered around the preservation of the ProtonVPN recommendation precisely, or is an attempt at lowering any bars for VPN recommendations now or in the future. If the Privacy Guides team reaches a decision that feature parity across OS platforms needs to be a mandatory requirement, and finds that ProtonVPN does not meet that criteria upon re-evaluation, then I will certainly respect that decision.

One of the main ideas that I am trying to drive home here is that outright removal/delisting does not inherently make clarity or safety better, but rather does the opposite by removing context. If ProtonVPN were to be completely erased from the VPN recommendations page, viewers who visit the website often will not be shown what or where in the criteria that it failed, and/or why the reason/criteria is important. Given that VPN services are typically selected based on the recommendations and marketing from various first-party and third-party sources, or from previous user experience, delisting from the PG site will not reduce usage in any meaningful way. Rather, this will simply remove PG’s ability to explicitly list limitations of the VPN entirely.

I do also sympathize and relate to the concern that uninitiated individuals should not bear the requirement of needing to visit multiple pages or re-synthesize recommendations. This is the reason that I am not saying that there needs to be a completely separate “recommended VPN clients” page, but instead I am conveying the idea of having much more clearer and visible distinctions between the actual VPN providers themselves and the actual VPN clients, putting any clear and noticeable limitations up front and center for readers to be aware of. A visible, up-front, and platform-specific “client not recommended” warning or message would convey much more than a complete absence of the product in question.

Responding to the mentions about feature parity across platforms, I personally do agree and acknowledge that this is also justifiable criterion. However, where I will counter this is that (as also acknowledged in this thread) parity and guarantees (which entails logging, monitoring, jurisdictional limits or laws, etc.) are never going to be unconditional. Evaluations of VPN providers will always need to have nuance because of differences in how and where they fall short. This proposal is attempting at detailing those shortcomings effectively instead of treating all failures as a binary pass or fail test.

I also understand the perspective of how the proposal could be taken as a signal for PG to “bend over backwards” for an individual provider, however I fully deny that this assumption is applicable here. This would still be benefitting Mullvad and IVPN because they would remain as full recommendations under both of the provider and client categories. However, Proton’s first party clients for macOS and Linux (or other platforms that have the kill switch issues) would be explicitly marked as not meeting the set standards both publicly and persistently. This would be clear and visible enforcement of PG standards and no exceptions or favoritism would be applied here.

The points that promises of “no-logs” and similar should not simply be blindly accepted with authenticity also hold true, which furthers my concern about false clarity. If we presently accept with mutual agreement that these assertions are nuanced and not absolute, then binary delisting itself doesn’t solve the communication issues, but shifts it elsewhere.

If the Privacy Guides team (Jonah and Co.) conclusively determine that binary-style recommendations are the only user-friendly way to keep confusion to a minimum, I will respect that as a valid philosophy. My main arguments simply point out that binary yes/no recommendations are only the safest option when the products being evaluated are themselves also binary. In reality, VPNs across providers, platforms, jurisdictions, and laws are unfortunately not that.

Even if this proposal is not accepted, I still hope to have provided useful contributions and suggestions that could be considered in the future at Privacy Guides, and I again thank everyone who took the time to read and consider this proposal with leaving honest thoughts and feedback for discussion.