Remove ProtonVPN

[kissu]

@dngray

then not reporting it to the marketing department (which the proton account on here is)

Not sure that everybody was aware of such.
Moreover, I don’t think it’s on us to deal with the fact that they brought a non-technical person on here.

Goodwill like RTings’ could be nice so that we can actually exchange back and forth with someone rather than having just a middle-person and no added value.
Moreover, the given person could have forwarded the concerns back to someone technical long time ago too.

Overall, a very weird angle to phrase it.

---

@dngray

I have found in the past working with proton developers directly does sometimes happen, but you have to show through support channels you have a reasonable amount of technical capability as to not waste their time

Same here, a lot of bending in every direction so far.
I do think that some evidence was given in some of the 280 previous messages already.

If the point is: let’s help someone get hired there so that they could fix the problem and report back here…I mean yeah sure. Kinda a lot of effort and investment into a company providing a service and definitely enough workforce to manage their own product given the (probably very public) raised concerns left and right.

@dngray

I haven’t really seen proper documentation besides some basic curl requests, and a lot of arguing without actually pinpointing the issue

I think that plenty of people gave enough already.
What would be the next step:

• sit next to a Proton employee in person
• open a code editor next to them on the same keyboard
• launch the project locally
• go through the stack trace
• apply the code changes to fix the problem
• let them press the final button so that they could commit the thing?

Yeah…that’s not what we call a reproduction/explanation of an issue here but a spoon-fed let-me-fix-it-for-you kind of situation.
Company’s priorities might be elsewhere regarding their growth but let’s not pretend they have incapable engineers that cannot grasp what’ they’re delivering.

—

@dngray

No software is perfect and that’s the world we live in.

True yet imagine if every company starts just using that lame excuse of throwing the ball to someone else and we’re just accepting/promoting it by keeping them in our recommendations under the “eh, it is what is is man, nobody knows how to code something nice nowadays, deal with that subpar product ” excuse.

[dngray (Daniel Gray)]

@kissu

Not sure that everybody was aware of such.
Moreover, I don’t think it’s on us to deal with the fact that they brought a non-technical person on here.

It’s a shared account to my knowledge. No they’re not going to staff it with their most experienced developers all the time. They may have used it in the past when available. I don’t really know.

@kissu

Goodwill like RTings’ could be nice so that we can actually exchange back and forth with someone rather than having just a middle-person and no added value.

It also varies depending on the size of the company. Some companies which are smaller, are likely developers. It doesn’t really matter though just judge based on what you see in their posts.

@kissu

@dngray

I have found in the past working with proton developers directly does sometimes happen, but you have to show through support channels you have a reasonable amount of technical capability as to not waste their time

Same here, a lot of bending in every direction so far.
I do think that some evidence was given in some of the 280 previous messages already.

Nothing specific, beyond “it doesn’t happen with pf, but it happens with Network Extensions”. Nobody managed to dig up that Apple technical notice (TN3165) which actually points out very clearly pf is deprecated with wording like:

It is not considered API. Do not use Packet Filter in a software product that you distribute to a wide audience. If you’re currently shipping software that relies on Packet Filter, plan to migrate to Network Extension.

(emphasis added) Is Proton expected to disregard Apple’s advice? What I would really like to know is why this happens, because it most certainly will be something that crops up with other VPN providers when they make the change.

@kissu

Yeah…that’s not what we call a reproduction/explanation of an issue here but a spoon-fed let-me-fix-it-for-you kind of situation.

Perhaps so, and maybe the reason is some sort of Apple issue, but to know really who is to blame someone has to do it. I do know that Proton does have an internal bug tracking system (their developers sometimes mention it on github), so maybe there is a specific reason this thing happens.

[ph00lt0]

It seems to me Proton’s macOS client leaks because macOS’s Network Extension model doesn’t give third‑party VPNs full, pre‑boot, system‑wide control. Proton chose to rely on NE alone, without adding a pf‑style firewall layer that could close many of those gaps. This is what Apple seems to push everyone towards too.
Apple’s architecture makes it nearly impossible to make a functioning kill switch. Other parties seem to rely on pf. While this may allow for some stronger enforcing, it seems hacky and not a durable solution, and I have to agree with @dngray that it is fairly clear that Apple is pushing everyone to NE and pf will not be possible in the near future.

Now what would be interesting is, if someone can actually pin point issues in the way that proton uses NE. If that is the case I would like to specifically zoom in on that.

[dngray (Daniel Gray)]

An Apple user sent me this:

Which does kind of sound like it’s intentional. Was the expectation that a VPN made you anonymous from Apple themselves? I think Proton VPN was very clear that’s not the case.

[dngray (Daniel Gray)]

@ph00lt0

hacky and not a durable solution

You’re not kidding there, I had a look at some of the source…

One of them uses bash scripts to manually pfctl -a rules which is a big no no sometimes if you’ve already got rules all sorts of things can happen. In Linux land we always use iptables-restore or nft -f to atomically load the rule set.

The other one uses a pfctl-rs a for-purpose library, but either solution isn’t ideal.

[privacy.slouchy]

I don’t think this specifically is apple exclusive, Android/AOSP isnt too different - even GrapheneOS users can’t force all network traffic through the VPN, captive portals & connectivity checks will not enter the VPN tunnel. Less to do with anonymity, more to do with basic network integrity

Now, letting app developers specify network traffic to not enter the VPN tunnel? That’s new to me

[dngray (Daniel Gray)]

@privacy.slouchy

captive portals & connectivity checks will not enter the VPN tunnel

Which is what you’d want otherwise you’d have no internet for the VPN to even work on.

@privacy.slouchy

Now, letting app developers specify network traffic to not enter the VPN tunnel? That’s new to me

There are reasons you’d want this, for example DHCP, and ICMPv6 you’d want not necessarily going into the VPN tunnel, especially as IPv6 does its router advertisements with that.

[privacycarrot]

@dngray

Nothing specific, beyond “it doesn’t happen with pf, but it happens with Network Extensions”. Nobody managed to dig up that Apple technical notice (TN3165) which actually points out very clearly pf is deprecated with wording like

I don’t think you can draw this conclusion from this TN, and it’s more of an uneducated guess rather than a definitive thing. The beginning of that article clearly explains why Apple says it shouldn’t be used in shipped apps:

macOS implements the BSD Packet Filter mechanism. This has two expected use cases:

• As an implementation detail of various system services built-in to macOS

• As an advanced feature for users, site admins, and so on

It is not considered API. <…>

Network Extensions are indeed much more maintainable than PF rules for app developers as they allow you to update your extension reliably without affecting the rest of the system. This is not possible with PF because the ruleset (even with anchors) is a global state shared between everything on your computer, so the more apps relying on it the more chances that something goes wrong. I also believe macOS apps can’t manage the firewall from within a sandbox, so an app which relies on it can’t be distributed on the Mac App Store.

I’m not Apple though, so who knows what are they up to but I’d be extremely surprised if they just removed a firewall from their base system without providing an alternative. Especially given they need this functionality themselves and they know users need it as well.

@ph00lt0

Now what would be interesting is, if someone can actually pin point issues in the way that proton uses NE. If that is the case I would like to specifically zoom in on that.

I don’t think this is an issue with how Proton uses it: Why we still don't use includeAllNetworks | Mullvad VPN

[Aflame-Blighted]

@Grapeg

If PG is not going to enforce its own criteria, then there is no point in having them

That makes me feel better about using LMDE7 instead of a recommended distro.

[dngray (Daniel Gray)]

@privacycarrot

I’m not Apple though, so who knows what are they up to but I’d be extremely surprised if they just removed a firewall from their base system without providing an alternative. Especially given they need this functionality themselves and they know users need it as well.

As far as I’m aware pf isn’t even available on iOS or at least it is not available or configurable for user-level firewall management.

Apple has consistently been striving for more convergence with macOS and iOS platforms. pf is something from the early days of MacOSX and I would say its days are numbered. When Apple tells you not to use something and to transition to something else, there’s a pretty good chance it will go. What the other VPN providers are going to do in this case is anyone’s guess.

I think Apple might rather work towards more of a “internet permission” type of thing which kind of makes sense its easier from the user perspective to think about “do i want to give this app permission to the internets” rather than “I want to open this tcp port”. One of the reasons why all those root-requiring garbage android firewalls sucked compared to the INTERNET permission GrapheneOS has.

My recommendation would be not to worry

@anonymous549

Any tool in any category that does not meet the minimum criteria should be removed, period. If PG is not going to enforce its own criteria, then there is no point in having them

The TLDR is the that kill switches are incredibly hard to get right, and on Apple platforms you have to do it the Apple way. Leaks have occurred on other platforms including Android.

If you’re serious about kill switches get a hardware router like one of those from Gl-inet or something, because that is really the only full-proof way of doing it.

I don’t think we should be punishing VPN providers which provide excellent infrastructure and audited open source applications because of limitations in the operating system and more specifically one specific platform which has a habit of being quite forceful about how things are done.

[jonah (Jonah Aragon)]

Current update: Following the changes at Remove IVPN - #22 by jonah the fact that Proton’s kill switch is not fully functional in all scenarios on macOS is no longer enough of a concern for us to warrant delisting it, because VPN providers cannot control platform limitations.

However, two issues with Proton remain:

1. The completely different problem to the macOS one that Proton has on Linux, which is described at ProtonVPN IP Leakage on Linux and Workaround | PrivSec - A practical approach to Privacy and Security remains an issue (which I confirmed with testing of course).

   The question here, I think, is whether this is a big enough problem to still consider Proton in violation of our current criteria, especially given that Proton specifically says to bind programs like torrent clients to the tunnel interface directly, which does solve this problem.

   To be clear, the kill switch on Linux is fully functional, unless an application specifically binds to the physical network interface. This, to me, seems like an issue which would warrant using something like Qubes, if protecting access to the physical network interface is of utmost importance to you, so I’d really consider this a platform limitation of Linux more than a Proton failure. Linux being extremely permissive with what you can do with it is a double-edged sword in this regard.

2. Proton still says that “the [killswitch] feature does protect you while switching servers with Proton VPN” which indeed remains demonstrably untrue on macOS. While this is no longer a technical issue for us, because of the criteria change above, it is still (IMO) a marketing issue with their misleading documentation.

   The question here is whether this marketing issue is enough to warrant de-listing Proton VPN. Historically, I believe we have never de-listed applications for misleading marketing alone.

Hopefully we can end the Apple-related discussions here: I think all of the talk about how NetworkExtensions work on macOS are a bit besides the point, and we should focus our discussion on these two problems above instead.

[jonah (Jonah Aragon)]

@jonah

this is no longer a technical issue for us

Also, to be clear, this does not mean we can’t note this fact anyways. Regardless of our decision on Proton, this PR is submitted to @team to review:

update: Warning about Proton kill switch on macOS (#3205)

[ignoramous]

@ph00lt0

Apple’s architecture makes it nearly impossible to make a functioning kill switch.

This is a misleading statement. NetworkExtension docs do mention that for VPNs using includeAllNetworks (a form of a ‘killswitch’) will prevent traffic from bypassing the VPN for advertised routes, for example, when apps may “scope” their traffic to a particular network interface.

@jonah

Proton specifically says to bind programs like torrent clients to the tunnel interface directly, which does solve this problem

If programs can bypass a VPN tunnel by merely binding to a specific interface, then that’s a leak, and definitely a ‘killswitch’ that’s horribly broken.

---

@dngray

There’s also a lot of spam in this thread. I’m not reading 272 replies

I linked to @xe3 reply for that reason. And there’s 2 or 3 other TLDRs similar to xe3’s.

Also see:

@jonah

• Has the poster failed to provide reasoning for their criticism, and demonstrated an unwillingness to learn or discuss the topic?
• Is the poster writing something as if it is true and informed, when they’re actually just speculating?

Btw, I encourage the mods to remove spam, and ‘the team’, who retain the ultimate responsibility for the content, read the thread if they want to arrive at an informed conclusion.

---

@dngray

They work as much as some application you run

Agree. This is the thread where the community has been having that discussion: Mention kill switch leaks caused by OS limitations

@dngray

VPN’s don’t provide high assurance and certainly not software apps running on the client. I certainly would not stake my personal security on the integrity of any of these apps from any VPN provider

I am of the same opinion, btw. I find this refreshing coming from a “team member”. PG should consider posting this on its VPN pages.

@dngray

It works but it’s a lot easier to ensure connections are protected when forwarding from one interface to another or dropping packets if the interface is down

What I meant to say was, one doesn’t need a VM to accomplish this. Up thread, @lyricism pointed this out, if you’d care enough to read the replies.

@dngray

none of these kill switches can be truly relied upon on any platforms as there have been issues on Android and other platforms

OS’ killswitch limitations must be addressed by OS developers. VPN client’s limitations must be addressed by the client developers:

• Some OSes (ex: Android, iOS/macOS) require VPN clients to be compatible with their (OS-provided) killswitch.
  • If there are leaks, the OS developers are on the hook to fix these.
• Some OSes (ex: Linux-based, macOS) provide mechanisms to setup (OS-assisted) killswitch which the VPN clients may use (these may require privileged APIs).
  • If there are leaks, the client developers may be need to use different APIs.

@dngray

No software is perfect and that’s the world we live in.

Only if there ever was a slippery slope not this slippery…

@dngray

worth noting that ProtonVPN is the only provider that supports port forwarding with natpmp.

Believe those “P2P” VPN servers exist in a separate pool plagued with bad IP reputation, no?

@dngray

thread has been brigaded from the people over at /r/privacy so consensus doesn’t really mean a lot

Why do you say so? The earliest mention of this thread on r/privacy I see is 3 days ago?

(funny that mods who admit they can’t be bothered to read the thread can reply immediately while those who have the context have to wait for 3h).

---

@jonah

over 100 unreasonable posts since my last reply a day ago.

I’m sorry but this reply reeks of total disrespect to folks who have been making the effort and taking the time to contribute here.

@jonah

@anonymous549

Could we atleast get an SLA

Sure, what is your budget?

Wrong question. There’s folks here who care about PG and would be more than happy to volunteer as team members or mods. How these folks get appointed or elected isn’t clear, however.

@jonah

I’m not sure what people expect here.

Think the expectation is, if there’s substantial discussion, the team weighs in more proactively. Especially when the team is very eager to make claims like…

@jonah

… generally stand by the idea that every statement on the site is accurate …

@Niek-de-Wilde

whats written on the site is generally perceived as the truth

---

@jonah

would encourage more community members to volunteer

Some of us do.

• On Android, "OS files are left unencrypted" · Issue #3179 · privacyguides/privacyguides.org · GitHub (open since Dec 2025)
• style: encrypted DNS prevents manipulation not spoofing by ignoramous · Pull Request #3166 · privacyguides/privacyguides.org · GitHub (open since Nov 2025)
• docs/os: AVB does not prevent evil maid by ignoramous · Pull Request #3183 · privacyguides/privacyguides.org · GitHub (closed because … “think with the input of GOS I’m going to go ahead and close this” with zero proof for that justification @fria made )

What’s the SLA, if any? It takes time and effort from volunteers, too, to engage with the team.

---

@dngray

Not really, and removing it would make us lose more credibility

This is an astonishing statement. Though, I have seen this movie before with NextDNS.

@dngray

@ignoramous

NextDNS’ “log storage location” feature is misleading in light of their use of all these other global service providers

This is largely speculation that GCP is logging everything regardless of a downstream privacy policy.

I do agree though they should be clearer about their sub processors though. Their Privacy policy is likely brief for brevity reasons (and maybe too much so).

Hopefully we hear back from them soon.

Hear back from them?

And, just who does PG prioritise building credibility with? Its readers or the corps?

@jonah

the kill switch on Linux is fully functional, unless an application specifically binds to the physical network interface. This, to me, seems like an issue which would warrant using something like Qubes

No.

[privacycarrot]

@dngray

As far as I’m aware pf isn’t even available on iOS or at least it is not available or configurable for user-level firewall management.

Apple has consistently been striving for more convergence with macOS and iOS platforms. pf is something from the early days of MacOSX and I would say its days are numbered.

It’s not a part of iOS or macOS, it’s a part of the XNU kernel (specifically the BSD part) and all Darwin-based operating systems (every Apple’s *OS) have it. So yeah, it’s part of iOS as well and you should be able to access it on a jailbroken phone.

What they are trying to do is they are trying to move anything that previously required a kext to the userspace so things like the Crowdstrike incident are not possible, and apps are as isolated from the system as possible.

[dngray (Daniel Gray)]

@ignoramous

@jonah

Proton specifically says to bind programs like torrent clients to the tunnel interface directly, which does solve this problem

If programs can bypass a VPN tunnel by merely binding to a specific interface, then that’s a leak, and definitely a ‘killswitch’ that’s horribly broken.

I know that qbittorrent has an option to do that in Tools > Options > Advanced > Network Interface. Transmission binds to 0.0.0.0 (all IPv4 interfaces) by default, it doesn’t bind to an interface just IPv4 address.

@ignoramous

@dngray

It works but it’s a lot easier to ensure connections are protected when forwarding from one interface to another or dropping packets if the interface is down

What I meant to say was, one doesn’t need a VM to accomplish this. Up thread, @lyricism pointed this out, if you’d care enough to read the replies.

I wasn’t suggesting you did either, but the issue is when everything shares the same routing table and there needs to be certain exceptions for the thing to work, and you’re hamstrung by the exposed features of the OS.

@ignoramous

@dngray

thread has been brigaded from the people over at /r/privacy so consensus doesn’t really mean a lot

Why do you say so? The earliest mention of this thread on r/privacy I see is 3 days ago?

We can tell how old accounts are obviously, and there are various threads spreading conspiracy rubbish, but I guess this is post-truth era after all where you don’t need proof of anything to make an accusation

@ignoramous

@jonah

over 100 unreasonable posts since my last reply a day ago.

I’m sorry but this reply reeks of total disrespect to folks who have been making the effort and taking the time to contribute here.

A good share of them don’t have any reasoning behind why they think we should do a particular thing though. None of them dug up Apple’s documentation or did any digging into why this happens beside it doesn’t with X provider that uses pf.

@ignoramous

@dngray

Not really, and removing it would make us lose more credibility

This is an astonishing statement. Though, I have seen this movie before with NextDNS.

What in saying that crappy software kill switches aren’t really reliable? I don’t think anyone should disagree with that.

[jonah (Jonah Aragon)]

@ignoramous

No.

Thank you for your analysis. I will share the most likely counterpoint for people to consider:

I think it’s probably fair to argue that on Linux you should be aware of what you are installing and what those programs are doing. A kill switch in this scenario that applies to the default network configuration is mainly going to protect you from random disconnects, while an intentionally misconfigured program set to bypass the kill switch by binding to a specific interface could be considered out of scope for what a mere software kill switch has to be doing.

This is compounded by the fact that the way to implement a kill switch on Linux is highly variable depending on distro and network configuration, there isn’t a single system API to plug into like on Android. In some sense if you are going to be performing sensitive tasks on Linux then you need to configure them properly, and if you don’t trust yourself and/or the application you need to be using the tool for the job that prevents this problem by design, which is Qubes.

Like I said, it’s an open question I’m presenting to everyone here, and I don’t really lean towards this argument one way or the other. I think…

@ignoramous

If programs can bypass a VPN tunnel by merely binding to a specific interface, then that’s a leak, and definitely a ‘killswitch’ that’s horribly broken.

…is also a perfectly valid opinion to hold, and if this is what we want to say then we could still de-list Proton. I don’t think it’s unreasonable to instead simply add a warning about this edge-case either though.

---

FYI: The rest of your post is frankly so off-topic to the Proton discussion we’re having in this thread, that if I were you I would not be surprised to see moderation action if you try to derail the Proton discussion with NextDNS complaints or organizational questions again.

[dngray (Daniel Gray)]

@privacycarrot

It’s not a part of iOS or macOS, it’s a part of the XNU kernel (specifically the BSD part) and all Darwin-based operating systems (every Apple’s *OS) have it. So yeah, it’s part of iOS as well and you should be able to access it on a jailbroken phone.

They may make it so it’s user land tools don’t exist, as that is the case on iOS you cannot configure pfctl. As for jail breaking that isn’t going to work on any remotely modern device and certainly something a VPN provider can’t depend on.

@lyricism

@ph00lt0

pf will not be possible in the near future.

Cite this if you are going to assert it please. I can not find any statement by Apple that they are planning to remove pf. It would be crazy if they did considering it’s what their own system services rely on under the hood.

They expressly say in TN3165: Packet Filter is not API

It is not considered API. Do not use Packet Filter in a software product that you distribute to a wide audience. If you’re currently shipping software that relies on Packet Filter, plan to migrate to Network Extension.

Then elaborate in Moving off packet filter and then in Test during the transition.

Apple doesn’t tend to announce things too much ahead, but I wouldn’t be surprised if it disappears in the next few years.

[jonah (Jonah Aragon)]

I think it’s becoming clear I will need to find all these Apple API posts and move them to a different thread since we can’t seem to move on from this topic?