Remove ProtonVPN

[Ganther]

@anon4374141

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.

I don’t know nor care about any of that. All of the stuff you linked boils down to platform-related issues during very specific scenarios.

The issue at hand here is very much fixable, AND happens during normal usage.

I find it very interesting that the two most ardent defenders of Proton in this thread registered in the past few days.

[anon4374141]

@Ganther

I find it very interesting that the two most ardent defenders of Proton in this thread registered in the past few days.

I don’t care what you do with Proton. I think the only things worth keeping from their service are Mail and Pass. I also don’t think public VPNs should be recommended the way PG does, unless your threat model is surveillance capitalism.

@privacycarrot

You can’t be serious.

Yes, I mean it. And since it’s already been clarified that it’s not that it fails to meet a specific criterion but rather that it has a particular bug on MacOS, I can now die in peace

And one more thing. You take internet discussions way too seriously, to the point of being rude.

[Ganther]

@anon4374141

And since it’s already been clarified that it’s not that it fails to meet a specific criterion but rather that it has a particular bug on MacOS, I can now die in peace

If you consider offering a broken kill switch to be offering a kill switch then sure. I think most of us would consider amateurish features to be non-existent features when it comes to such an important feature.

Would be interesting to see the results of the poll to see if that’s the case.

[lyricism]

@anon4374141

it’s already been clarified that it’s not that it fails to meet a specific criterion but rather that it has a particular bug on MacOS

You are sorely mistaken. It is not a bug that’s the issue, it’s a core design deficiency that causes them to not meet the criterion.

@anon4374141

when there is no mention in the PG criteria of a ‘hierarchy’ of flaws or anything of the sort.

This is just false. There are best case criteria and minimum criteria for a recommendation by PG. Best case criteria are pluses if they are met, whereas something is not supposed to be recommended if it doesn’t meet all of the minimum criteria.

A minimum to qualify criterion for VPN services on PG is:

• Kill switch built in to clients.

I think we could go back and forth about where the line is with what actually qualifies as a kill switch, but I think you’d have to do some serious gymnastics to argue that a kill switch doesn’t need to prevent leaks during server switching.

In fact, as already demonstrated in this thread, Proton themselves consider this to be a part of a standard kill switch

@Overall-Bet3743

On ProtonVPN’s official website they claim that “[regular kill switch] does protect you while switching servers with Proton VPN” : What is a kill switch? | Proton VPN

The issue at hand in this thread is that ProtonVPN’s client on macOS does not protect against leaks when just switching servers. Not disconnecting and reconnecting, we’re talking about a situation where you are already connected and just pick a new server.

@Overall-Bet3743

according to ProtonVPN themselves : Reddit - The heart of the internet - “Kill Switch on Mac will not prevent your device from connecting to the internet during manual disconnection events as you’ve described above.”

@Overall-Bet3743

In that post, multiple people responded saying that their IP is indeed being exposed during server switches. A reddit post from one month ago also complains of the same issue: Reddit - The heart of the internet

@Overall-Bet3743

ProtonVPN confirms that : “For this, you would need Advanced Kill switch, available on Windows and Linux only: How to use advanced kill switch | Proton VPN”

The issue has also been tested and confirmed in this very thread

@privacycarrot

ProtonVPN

1. Does my IP leak when I switch VPN servers?

 % curl --interface en0 https://ifconfig.me
xx.xx.xx.xx%

% curl --interface utun6 https://ifconfig.me
curl: (45) Couldn't bind to 'utun6'

While the tunnel interface is down the default interface leaks my real IP.

This is not a platform limitation, as Mullvad does not have the same issue

@privacycarrot

Mullvad

1. Does my IP leak when I switch VPN servers?

% curl --interface en0 https://ifconfig.me
curl: (6) Could not resolve host: ifconfig.me

% curl --interface utun6 https://ifconfig.me
curl: (6) Could not resolve host: ifconfig.me

All good here, Mullvad drops traffic to both interfaces while I’m switching servers.

What is the point of defining minimum criteria if providers will be allowed to be listed while not meeting them?

[anon4374141]

Does Mullvad have a kill switch in the Android client? I think, following your own reasoning, you’d have to do quite a few gymnastics to argue that it does (by your definition). On GrapheneOS it can be resolved, but on all Android devices (which are the vast majority), every time you connect to a Wi-Fi network you suffer a data leak.

Can Mullvad fix it? No. And Proton with respect to macOS? Yes. There’s no argument here, I’m conceding your point, but please think a bit more globally: this isn’t about defending one company over another, I couldn’t care less.

What’s the point of using a VPN if it’s going to have leaks? If you want to be anonymous, you use, for example, TAILS (not Proton, not Mullvad, not iVPN). If what you’re concerned about is hiding the pages you visit from your ISP, in my opinion ProtonVPN will serve you perfectly well on macOS despite those leaks when switching servers.

As was said above, but it seems the eagerness to cross Proton off the list is overriding your ability to actually listen to the arguments:

@dadnerd

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.

And I keep bringing this topic up precisely because, as @Jonah said when closing the Remove iVPN thread, this touches on a much broader discussion:

@jonah

I am going to close this as an invalid duplicate (thereby returning votes), because I believe it is the exact same problem as Remove ProtonVPN, and whatever solution we reach in that thread would also apply here. If there is a different, unrelated reason to remove IVPN please open a new thread.

[ignoramous]

@anon4374141

What’s the point of using a VPN if it’s going to have leaks?

Yeah, you’re asking the right questions… for this thread here: Mention kill switch leaks caused by OS limitations

@anon4374141

On GrapheneOS it can be resolved, but on all Android devices (which are the vast majority), every time you connect to a Wi-Fi network you suffer a data leak.

I don’t know what you’re talking about here with respect to Android. Link, if any, please? Thanks.

[anon4374141]

@anon4374141

Android: Leak when connecting to a Wi-Fi network: Android leaks connectivity check traffic | Mullvad VPN

Here

[Blackbird]

October 10, 2022??

[anon4374141]

As far as I understand, it hasn’t been resolved yet.

[any1]

[Blackbird]

Seems like you were right. I haven’t noticed it since I have GOS, and I disabled the connectivity checks on the other phone with adb.

adb shell settings put global captive_portal_mode 0

[lyricism]

@anon4374141

Does Mullvad have a kill switch in the Android client? I think, following your own reasoning, you’d have to do quite a few gymnastics to argue that it does (by your definition). On GrapheneOS it can be resolved, but on all Android devices (which are the vast majority), every time you connect to a Wi-Fi network you suffer a data leak.

I suggest you actually read the thread you’re posting in. There’s already broad agreement that platform limitations should not affect the recommendations, but the ProtonVPN macOS issue isn’t a platform limitation.

@anon4374141

Can Mullvad fix it? No. And Proton with respect to macOS? Yes.

And you don’t see a difference there??

@anon4374141

this isn’t about defending one company over another, I couldn’t care less.

You spend a lot of your time defending Proton against already proven allegations of a deficiency in their product in a thread on a forum you joined three days ago for someone who “couldn’t care less”. I don’t mind if you do care either to be clear, just please be honest about it.

@anon4374141

it seems the eagerness to cross Proton off the list is overriding your ability to actually listen to the arguments

I can’t help you if you’re just going to be fighting with ghosts.

The eagerness to cross Proton off the list is because they have an issue in their software they are fully capable of fixing but won’t which causes them to not meet the minimum requirements to be recommended by PG.

@anon4374141

If you want to be anonymous, you use, for example, TAILS (not Proton, not Mullvad, not iVPN)

Maybe you’re confused but this forum is Privacy Guides not Anonymity Guides

@jonah

I am going to close this as an invalid duplicate (thereby returning votes), because I believe it is the exact same problem as Remove ProtonVPN,

@jonah is wrong there, that is a different issue about iOS which is a platform limitation. This thread is about an issue on macOS which is not a platform limitation.

[dada_goose]

I can’t understand @anon4374141 ‘s argument at all, it seems to completely miss the point. However, surely now is the time for @jonah or another from the PG team to close this thread and make a decision either way? Why is this still ongoing?

[anon4374141]

I have given you data and what remains is to ask that the thread be closed or to point out that my arguments must be worth less because I registered 3 days ago. You already stopped arguing, I understand. But simply to note that the position I was defending looks quite a lot like @Jonah’s:

@jonah

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

I suppose here he was also completely wrong, or that Proton is paying him. So I don’t think I was going off-topic at all. That said, I’m going to stop replying, no need to close the thread.

[anonymous549]

@anon4374141

That said, I’m going to stop replying

Damn @lyricism you finally broke him. Dude even deleted his account.

[lyricism]

State of the thread

[ph00lt0]

the question i still have is, is it really a fault of proton or apple?

[lyricism]

Earlier in the thread @privacycarrot tested and confirmed the issue is specific to ProtonVPN by comparing against Mullvad

@privacycarrot

Mullvad

1. Does my IP leak when I switch VPN servers?

% curl --interface en0 https://ifconfig.me
curl: (6) Could not resolve host: ifconfig.me

% curl --interface utun6 https://ifconfig.me
curl: (6) Could not resolve host: ifconfig.me

All good here, Mullvad drops traffic to both interfaces while I’m switching servers.

@privacycarrot

ProtonVPN

1. Does my IP leak when I switch VPN servers?

 % curl --interface en0 https://ifconfig.me
xx.xx.xx.xx%

% curl --interface utun6 https://ifconfig.me
curl: (45) Couldn't bind to 'utun6'

While the tunnel interface is down the default interface leaks my real IP. It seems like there’s a window after you initiated server switch and before it you’re actually connected to the new server during which you’re leaking your real IP. Note that that window doesn’t start right after you initiated server switch but it starts at some point later.

[Ganther]

Did you read the thread?

Am I being whooshed?

[dngray (Daniel Gray)]

For the strongest security regarding VPN kill switches, we always recommend hardware solutions, such as a pocket router or a router in general.

We are not removing Proton VPN for something that amounts to a platform implementation issue with macOS/iOS (making it Apple’s responsibility).