Who owns Express VPN, Nord, Surfshark? VPN relationships explained (2024)
Reactions to the VPN relationship map
- Many found the ownership/relationship graph “scary” and eye‑opening, especially how few entities control many “independent” brands.
- People appreciated direct links to the full, zoomable map and asked for exports or text outlines.
- Some noted it’s ironic the exposé comes from another commercial VPN provider, which itself must be scrutinized.
Ownership, corporate ties & geopolitics
- Heavy focus on Kape Technologies (ex‑Crossrider, adware/malware legacy) owning major brands like ExpressVPN and PIA; this alone put them in the “avoid” bucket for many.
- Tesonet’s role behind Nord, Surfshark and links to Proton sparked long debate:
- One side sees ordinary outsourcing/HR partnerships and later separation.
- The other sees unexplained key sharing, employee “sharing,” and aggressive PR/legal behavior as red flags.
- Several raised concerns about links to Israeli Unit 8200 and analogous intelligence ties in other countries, arguing VPN operators are prime surveillance assets.
Trust, logging & data monetization
- A commenter claiming to have bought data from “major VPNs” described:
- DNS harvesting, traffic metadata resale, “injected” surveys/ads, and even p2p-style VPNs doubling as commercial botnets.
- Others questioned how much can be done given HTTPS, concluding that metadata (DNS, SNI, timing, volume, device info) alone is highly valuable.
- Skepticism is widespread: many believe 95–99% of VPNs monetize user data in some way, especially “free” ones.
Which VPNs are relatively trusted
- Frequently mentioned as “less bad”: Mullvad, Proton, IVPN, AirVPN, Windscribe.
- Mullvad praised for minimal signup and quality clients, but criticized for dropping port forwarding and heavy IP blocking by some services.
- Proton liked for its ecosystem and crypto design, but some distrust its expansion into a “Google‑like” suite and the Tesonet/Radware controversies.
- PIA was once trusted but many now avoid it post‑Kape acquisition.
Use cases: when VPNs help vs don’t
- Common legitimate uses:
- Geo‑unblocking (streaming, regional services, travel), torrenting, bypassing ISP logging/retention, defeating hotel/campus throttling/filtering, public Wi‑Fi eavesdropping, evading local speech laws or censorship.
- Many stressed a VPN doesn’t provide strong anonymity, doesn’t stop fingerprinting, and simply shifts trust from ISP/government to a commercial operator—sometimes in a riskier jurisdiction.
- Several argued most people “don’t need” a consumer VPN; for high‑risk activism/whistleblowing, Tor or more complex setups are preferred.
Technical privacy nuances
- Long subthreads on:
- HTTPS vs VPN: VPN hides destinations from local network/ISP but not from VPN provider; HTTPS still leaks hostnames via SNI unless ECH is used.
- WPA2 vs VPN on public Wi‑Fi: shared networks allow easy local interception; VPN meaningfully reduces local attack surface.
- DPI and traffic analysis: even without decryption, ISPs and states can infer behavior from IPs, sizes, timing, and patterns.
Self-hosted VPNs and SSH tunnels
- Many recommended rolling your own via WireGuard/OpenVPN on a VPS, or SSH SOCKS5 tunnels, sometimes fronted by tools like Tailscale or Amnezia.
- Downsides: DC IPs are widely blocked or CAPTCHAd, VPS egress can be expensive, and static single‑user IPs are easily linkable across sites.
New approaches: verifiable VPNs & Multi‑Party Relays
- Some promoted “verifiable” VPNs using TEEs (Intel SGX/TDX) and reproducible builds so clients can cryptographically attest what code is running.
- Others pushed Multi‑Party Relays (e.g., one provider for entry, another for exit, such as Obscura + Mullvad) to avoid any single party seeing the full picture.
Overall sentiment
- Strong cynicism: consumer VPN marketing is seen as FUD‑driven, with opaque ownership and weak guarantees.
- Yet VPNs remain widely used for narrow, pragmatic reasons (geo, torrents, local ISP avoidance).
- Consensus: don’t expect anonymity; treat any VPN as moving, not removing, the surveillance problem, and choose providers and architectures that minimally require trust.