{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifwfhm2wmz5eqopjmknqho3yaziczdzfwakka3kk3xiggacxpilrm",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mgr3vkea2m72"
  },
  "path": "/t/what-should-we-require-of-vpn-providers-on-macos/36175?page=2#post_32",
  "publishedAt": "2026-03-11T03:56:43.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "documentation",
    "observed behavior",
    "past usage patterns"
  ],
  "textContent": "privacycarrot:\n\n> Now, kill switches are a very unique use case and NE doesn’t provide any functionality to implement them. `includeAllNetworks` is not the one based on documentation, observed behavior and past usage patterns.\n\nDocumentation for `includeAllNetworks` is clear on what kinds of traffic will be not sent to the VPN app.\n\nMullvad’s blog post is concerned with other bugs related to `includeAllNetworks`, not any perceived leaks.\n\nMjtsai’s blog is how things are in heavily sandboxed worlds of iOS and Android (where the OEM / 1p apps run with higher privileges and call the shots).\n\nprivacycarrot:\n\n> restricted to Network Extensions only, so no kill switch\n\nDiscounting “Always-on VPN” (available only on ‘supervised devices’ , not sure why you qualify Network Extensions as having ‘no killswitch’ when it in fact, within the boundaries acceptable to Apple for iOS, `includeAllNetworks` is exactly that? If VPN apps won’t use this killswitch, then Network Extensions will provide even worse guarantees with respect to leaks. The leaks that do happen due bugs with `includeAllNetworks` is for Apple to fix.\n\n* * *\n\njonah:\n\n> actual WireGuard client\n\nFrom a quick glance at the code repo, the official WireGuard client for Apple devices doesn’t seem to use `includeAllNetworks`, so it’ll be strictly worse than apps that do, no matter what else it might be doing to prevent leaks.",
  "title": "What should we require of VPN providers on macOS?"
}