How should we handle Proton's misleading marketing?

[win11.shading291]

@dngray

I would highly suggest customers of Proton report this.

Hi, already have done this in the past and only received a generic PR answer (on lumo open source)

[jonah (Jonah Aragon)]

I’ll YouTube it

Video demo: Proton kill switch not working as described on macOS

PeerTube above, but published to YouTube for reach

[ignoramous]

@Ganther

If it’s incorrect for years and they never fix it, then it’s intentional to make the product look good.

Apropos of a sister thread on “Proton’s misleading marketing”… someone should dig up more on their “Suisse cheese law is the best” drivel.

@ignoramous

@Julie

The curent case was a criminal one, so it would not apply.

Sure. For criminal cases, the Budapest Convention applies, the latest (more privacy invasive) iteration of which was put out for signatories to join pretty recently. Regardless, whatever marketing claims Proton and Quad9 are making fall flat.

@Julie

You own text cited, indicate that the Lugano convention is for civil and commercial matters.

I know? I cited Lugano to make it clear that Proton’s marketing that Swiss laws (as far as LEA is concerned) are some kind of a shield is a farcical claim at best.

[Gopher]

Warning about its limitations in certain use cases sounds appropriate. Privacy Guides lists Firefox as a recommended desktop browser, even though you’d need to get something like Arkenfox installed for it to even be considered in the same league as something like Mullvad browser or Brave.

From what I understand ProtonVPN is still great if you’re on a device like Windows, Android, and (I think) Linux, so it’s safe to recommend it to people who will use it in those cases.

[Proton_Team]

Duping this from another thread:

Hi folks, just some notes from the Proton VPN team that may be helpful, and some updates on what we are working on in this area:

Kill Switch for Linux

The Proton VPN Linux kill switch (https://protonvpn.com/support/advanced-kill-switch, as of v4.2.0 and above) uses a routing-table enforcement model that is standard for Linux networking. All outbound traffic is forced through a non-routable sink interface unless the VPN tunnel is active. This prevents applications from leaking traffic during unexpected disconnections.

A scenario highlighted in this discussion involves an advanced user manually binding an application with the appropriate privileges to a physical network interface. Such bindings intentionally bypass the system routing table and therefore bypass any routing-based firewall or kill-switch mechanism.

For typical users operating in a default environment, the kill switch prevents leaks as designed. For advanced users who intentionally create custom routing or interface-level rules, then naturally having the VPN interfere with this would be undesirable. However, we are actively evaluating additional enforcement layers to provide stronger safeguards against accidental misconfiguration - but without interfering with intended user behaviour.

MacOS Server Reconnection

A valid concern was raised about IP exposure during server switches on macOS. There are some mitigations against this in place - users are warned before switching servers that their VPN connection may be briefly interrupted, and users using any VPN on any platform are advised to bind to the VPN interface when torrenting (https://protonvpn.com/support/bittorrent-vpn). This is not, however, as robust as we would like.

As some posts in this thread have already pointed out, kill-switch limitations on macOS stem more from the OS itself, rather than specific individual VPN implementations. These limitations are documented in our knowledge base, but based on the feedback that we have received, we are presently revising them for clarity and to ensure that no one is inadvertently misled as to how Proton VPN handles these limitations. Proton VPN uses Apple’s Network Extension framework, which provides only limited control over how the operating system handles traffic during transitions such as tunnel renegotiation. Apple’s networking stack restricts low-level firewall and routing manipulation, making certain enforcement mechanisms that exist on other platforms technically impossible or unreliable on macOS.

Despite these platform constraints, we recognise that users expect the kill switch to behave as a leak-prevention mechanism across all operating systems, and ideally without additional measures being required by the user for their protection. To address this expectation, we had already started exploring alternative approaches on macOS to ensure that ProtonVPN meets both our internal standards and the strict criteria valued by this community.

An alternative used by other VPNs involves a tunnel interface set up by a daemon that runs without a sandbox on the user’s machine with elevated privileges. We did consider this solution, but rejected it. The legacy APIs that are used are ones that Apple has heavily signalled that they intend to deprecate, so this was not going to be a long-term, reliable solution.

What we are doing instead is baking the protections into the network stack itself to ensure that the protected tunnel must always be retained even when the connection is interrupted - either accidentally, or during server switches. This new cross-platform network architecture was the main thing that we were working on during our Autumn/Winter roadmap cycle (https://protonvpn.com/blog/product-roadmap-winter-2025-2026#:~:text=a%20random%20country.-,A%20new%20VPN%20architecture,-A%20powerful%20and). We haven’t officially announced our Spring/Summer roadmap for Proton VPN yet, but we can confirm now that we will be rolling this out in the first half of the Spring/Summer roadmap cycle.

We will publish updates as these start to roll into beta and production, and we welcome feedback from privacy-focused users who want to contribute insights.

[Overall-Bet3743]

@Proton_Team

There are some mitigations against this in place - users are warned before switching servers that their VPN connection may be briefly interrupted

Where are they warned about this? @jonah made a video demonstrating the issue and I don’t see this warning anywhere. I have also been unable to find any documentation stating that the user’s IP would not be protected during server switches. In fact in the video, the “You are not connected” message that you see when you manually disconnect from the VPN actually seems to be blurred out during server switches, obfuscating to the user that they are effectively in the same state as if they had manually disconnected and where in the process of manually connecting to another server.

@Proton_Team

kill-switch limitations on macOS stem more from the OS itself, rather than specific individual VPN implementations. These limitations are documented in our knowledge base

You have documented the following:

Important note: As we have reported, Apple’s macOS and iOS operating systems don’t close all existing connections when you connect to a VPN, specifically certain DNS queries from Apple services, even with the kill switch turned on. However, the kill switch will block all non-Apple connections. We’re aware of this issue, and are working towards a possible fix.

This is not at all the same issue.

@Proton_Team

Proton VPN uses Apple’s Network Extension framework, which provides only limited control over how the operating system handles traffic during transitions such as tunnel renegotiation. Apple’s networking stack restricts low-level firewall and routing manipulation, making certain enforcement mechanisms that exist on other platforms technically impossible or unreliable on macOS.

Can you give an official response to this post which claims that ProtonVPN’s macOS client is solely relying on includeAllNetworks in its kill switch implementation (with no backup) and states that the kill switch failure could be due to:

@Overall-Bet3743

2. ProtonVPN’s macOS client calls exit(0) on the WireGuard system extension, which hosts the NEPacketTunnelProvider subclass. This exit(0)method of stopping the tunnel is used for both server disconnects and server switches and prevents includeAllNetworks from functioning correctly and blocking the user’s connection.

The apparent reason for using this exit(0)method is due to an old Apple bug that would crash NEPacketTunnelProvider that has seemingly since been fixed. It seems that ProtonVPN would have unscrupulously implemented a proposed fix that had this side effect.

If the above is true, would you not characterize that as an implementation failure on ProtonVPN’s behalf?

@Proton_Team

An alternative used by other VPNs involves a tunnel interface set up by a daemon that runs without a sandbox on the user’s machine with elevated privileges. We did consider this solution, but rejected it. The legacy APIs that are used are ones that Apple has heavily signalled that they intend to deprecate, so this was not going to be a long-term, reliable solution.

ProtonVPN initially launched the macOS kill switch with Packet Filter (source).

• When did ProtonVPN receive these heavy signals from Apple?
• When did you decide to stop using Packet Filter?
• When was the server switch IP leak issue first introduced?
• For how long have you known about this server switch IP leak issue on macOS?

You may think this is semantics, but an apple engineer made this statement in 2025 with respect to Packet Filter (what you dub ‘legacy API’) :

Well, we can’t deprecate something that we’ve never officially supported as an API

The big question with respect to this thread is : why did you not make this issue known to your customers and prospective customers?

[lyricism]

@Proton_Team

we welcome feedback from privacy-focused users who want to contribute insights.

Nothing in this post addresses the misleading documentation and marketing materials which this thread is supposed to be about.

[Encounter5729]

@Proton_Team

Hi folks, just some notes from the Proton VPN team that may be helpful, and some updates on what we are working on in this area:

First, thanks for responding here. Greatly appreciated.

@Proton_Team

A scenario highlighted in this discussion involves an advanced user manually binding an application with the appropriate privileges to a physical network interface

This sentence is misleading as well. The whole operation doesn’t require sudo, neither for ifconfig, neither for curl. Theoretically, any application allowed to run terminal command* can therefore know your true IP address.

• I believe that’s every Linux app, I don’t even know if Flatpak restricts this.

@Proton_Team

We haven’t officially announced our Spring/Summer roadmap for Proton VPN yet, but we can confirm now that we will be rolling this out in the first half of the Spring/Summer roadmap cycle.

So this means around July ?

I think the issue is you treat this as just another feature, but many users view a reliable killswitch as a must-have. Per jonah, it’s been 2 years since this issue (macOS leaks) was reported. What have you done in that time ?

Either you don’t value security/privacy of this product, your team is understaffed or the issue was never communicated to you by the Proton social media team. In any of those case, this raises big concerns.

[Proton_Team]

Fair pushback, let us be more direct than our last response was. The current implementation of the macOS kill switch does not reliably protect IP during server switches.

There was an in-app alert, but it required context to interpret correctly, and our KB articles weren’t explicit enough about this limitation.

We’ve updated both:

• The KB article has been revised and is live here.

• We’re updating the in-app kill switch modal to state the risk plainly, which will be rolled out with the next update: "Disables internet if the VPN connection drops to prevent accidental IP leak. Your IP may be briefly visible when switching servers.

  

The deeper fix is already in progress. We’ve been rebuilding our network stack with a native WireGuard implementation, developed in-house, that includes a native kill switch maintaining the tunnel through server switches. Like we mentioned previously, the timeline for the fix is within the first half of our Spring/Summer roadmap cycle.

On why this wasn’t surfaced more clearly to users sooner: we don’t have a satisfying answer. Our user base has historically skewed toward Windows and mobile, and Mac had not received the same level of documentation scrutiny. To be clear, we are not trying to justify this, however it’s important to provide context for why the gap existed and went unaddressed longer than it should have.

We’re reviewing how security-relevant limitations get flagged in both our KB process and in-product copy going forward.

[dngray (Daniel Gray)]

Just from my other post, you can actually derive quite a bit out of @Proton_Team’s previous post when you know what the Apple requirements are to be in the App Store.

Proton’s solution will almost certainly be 100% better than the competitors as it won’t rely on getting around any of the sandboxing features (SIP/CSR/AMFI etc) and will actually work on iOS where there isn’t any pfctl or root ability.

[lyricism]

@dngray

will actually work on iOS where there isn’t any pfctl or root ability.

They have only commented on macOS and describe deploying their own Wireguard implementation to fix the issues there. I don’t think the Wireguard implementation is the issue on iOS, it is how the OS handles VPN connectivity and is not really something that can be worked around by an app. I don’t know where you’re getting the idea their proposed solution will also resolve the iOS issues from.

[dngray (Daniel Gray)]

@lyricism

proposed solution will also resolve the iOS issues from

Because they need it fixed on both platforms obviously, and those platforms are not too dissimilar from each other these days in terms of security features and requirements.

In terms of the kill switch, I doubt it’s specific to anything to do with wireguard, because that’s just the tunnel nothing more.

[jonah (Jonah Aragon)]

@dngray

I doubt it’s specific to anything to do with wireguard, because that’s just the tunnel nothing more.

There are some suggested ways to largely fix this in-app, described at What should we require of VPN providers on macOS? - #77 by Overall-Bet3743 for example.

Which essentially comes down to: there’s no reason the packet tunnel exposed to the OS using Apple’s API is the same as the actual tunnel to Proton’s servers that the app uses. The Proton client could(?) switch WireGuard tunnels without tearing down the tunnel macOS sees, I believe.

[lyricism]

@dngray

doubt it’s specific to anything to do with wireguard

I agree but I would speculate as part of that they would rework the entire app’s handling of connection management to work with the new implementation and resolving the kill switch issues is moreso just a side effect of that, despite them kind of framing it as something they’re doing because of the issues.

I admit I’m speculating though. I don’t think they actually gave much detail here to go off of. Also possible it will help with issues on iOS in a similar way, sure, I just don’t think we really have anything from them specifically indicating that yet and my understanding is the iOS issues are not really able to be worked around in the same way they maybe can be on macOS so I’d be skeptical (though I am admittedly less up to speed on the iOS issues). It’d be cool if you’re right though.