{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicelo4gxd7vccsgzpzlklqxpkcyh3khq6m6wycmmps4rqf35ehwaq",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mgr3usee3zt2"
  },
  "path": "/t/what-should-we-require-of-vpn-providers-on-macos/36175?page=2#post_34",
  "publishedAt": "2026-03-11T04:30:13.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "Remove ProtonVPN"
  ],
  "textContent": "jonah:\n\n> think the crux of the issue is that `includeAllNetworks` simply does not appear to cover the case where you disconnect from the VPN _in order to connect to a different server_ , when it probably should. This is what most people would consider normal kill switch behavior\n\nGotcha. Without the `includeAllNetworks` flag, _any_ 3p app can bypass the VPN on iOS / macOS _at will_. With that flag, 3p apps would be able to bypass only in those specific scenarios that trigger Apple’s implementation bugs. Two very different things.\n\nSimilar points were made across multiple threads in multiple replies… here’s one:\n\nRemove ProtonVPN\n\n> Security is usually a shared responsibility. If there’s a “killswitch” then a client is better off using it, because if it doesn’t, all bets are off. The traffic may then leak not just because of the OS’ shortcomings but also because of the VPN client’s. The latter is in the control of the VPN provider, the former is not.\n>\n> For example, VM & sandbox escapes do exist (due to bugs in the implementation or bugs in the OS/Kernel); but that doesn’t mean projects like Whonix/Chrome put the towel in and abandon isolation/sandboxing. Those projects must continue to use the tools made available to them by the OSes and sandbox/isolate to the extent feasible. Without them doing that, all bets are off.",
  "title": "What should we require of VPN providers on macOS?"
}