How should we handle Proton's misleading marketing?

[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?