VPN Protocols, Logging Claims and Jurisdiction: Reading Past the Marketing

What a VPN changes on the wire, precisely

If you want the plain-English version of how VPNs work at all, the foundation guide covers that ground. This piece starts where that one ends: with the technical record, the legal reality, and the limits of what any VPN can provably guarantee.

When you connect through a VPN, your device establishes an encrypted tunnel to a server operated by the provider. Every packet leaving your machine is encapsulated inside that tunnel before it touches your ISP's infrastructure. From your ISP's perspective, they see a sustained encrypted connection to a single IP address. They cannot read the contents, and they cannot see which destinations you're ultimately reaching. That part is real and it matters.

What changes, precisely: the IP address that destination servers log against your requests becomes the VPN server's address rather than your own. Your ISP's traffic logs show volume and timing to the VPN endpoint, but not the underlying destinations. DNS queries, if handled correctly by the provider, go to the provider's resolvers rather than your ISP's, which closes a common leakage point.

What does not change: the content of your requests once they leave the VPN server. The provider's server makes the outbound connection on your behalf, so the provider is now the party with visibility into your unencrypted traffic (where it's unencrypted), your DNS queries, and the metadata of every session. You've moved trust, not eliminated it. That's the honest framing, and every evaluation question that follows flows from it.

Practical takeaway: Before evaluating any provider's claims, write down what threat you're actually addressing. If it's ISP-level surveillance or geolocation, a VPN addresses it directly. If it's something else, check whether you're in the right tool category at all.

Protocols in practice: WireGuard, OpenVPN, and proprietary wrappers

The protocol a provider uses determines the cryptographic primitives in play, the attack surface of the implementation, and, practically, how the connection behaves on hostile networks. These are not equivalent choices.

WireGuard

WireGuard is a relatively recent protocol, merged into the Linux kernel in 2020, with a codebase that is deliberately small. The design philosophy is that a smaller codebase means a smaller auditable surface. It uses a fixed, modern cryptographic suite: Curve25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing. You cannot negotiate down to weaker ciphers, which eliminates a whole class of downgrade attacks that have historically troubled TLS-based protocols.

The tradeoff is flexibility. WireGuard's fixed cryptographic choices mean that if a weakness is found in one of those primitives, there's no fallback. In practice, those primitives are currently considered strong, but it's worth understanding that the protocol's simplicity is a deliberate design constraint rather than an oversight.

There's also a privacy consideration baked into WireGuard's original design: it was built to associate a client's IP address with a public key on the server, and that association persists until the server is restarted or the table is explicitly cleared. Several providers have built additional layers around this, sometimes called double-NAT approaches, to avoid retaining that mapping. Whether a provider has actually implemented this, and how they've documented it, is a concrete question you can ask.

OpenVPN

OpenVPN is older, slower on modern hardware, but extremely well-understood. It runs over TLS, which means it can be configured to use a range of cipher suites, and it can be tunnelled over TCP port 443 in a way that makes it difficult to distinguish from ordinary HTTPS traffic. That makes it more robust on networks that actively block VPN protocols, which is relevant in some corporate environments and in countries with active deep packet inspection.

The configurability is both its strength and its weakness. A well-configured OpenVPN deployment is solid. A poorly configured one, with weak cipher negotiation enabled or certificate validation skipped, is considerably less so. When a provider says they use OpenVPN, the meaningful follow-up question is what their default configuration actually enables.

Proprietary protocols

Several large providers have developed their own protocols: Lightway (ExpressVPN), NordLynx (a WireGuard implementation with additional layers), Hydra (used by several providers under licence). The marketing framing is usually speed and reliability, and some of those claims have merit. The problem is auditability.

An open protocol like WireGuard or OpenVPN can be independently reviewed by anyone with the relevant expertise. A proprietary protocol's security depends on the provider's internal engineering quality and whatever external review they've commissioned. That's not automatically worse, but it requires you to place more weight on the audit record, because the code itself isn't open to general scrutiny. Some providers have published audits of their proprietary implementations. Many haven't.

There's also the question of what a proprietary protocol is actually built on. Most are wrappers around established primitives rather than novel cryptographic designs, which is sensible. Novel cryptography is almost always a red flag.

Practical takeaway: Check which protocols a provider offers and whether their default is configurable. If they use a proprietary protocol, look for a published audit of that specific implementation, not just of their server infrastructure.

The "no logs" claim: what is technically checkable and what is trust

"No logs" is the most repeated phrase in VPN marketing and the least examined. It's worth pulling it apart carefully, because it conflates several distinct claims that have very different levels of verifiability.

There are broadly three categories of data a provider could log: connection logs (timestamps, source IP, assigned VPN IP, session duration), traffic logs (DNS queries, destination addresses, payload content), and account-level data (email, payment method, subscription status). Most providers who make a no-logs claim are specifically disclaiming connection and traffic logs. Account-level data almost always exists in some form, because providers generally need it to manage subscriptions.

The technically checkable part is narrower than it sounds. You can verify, through an audit, that a provider's servers are not configured to write connection or traffic logs to disk at the time of the audit. You cannot verify, from outside, that the provider hasn't been served with a legal order requiring them to begin logging a specific user prospectively. You cannot verify that there's no logging at a network layer above the server, for instance at the data centre or upstream provider level. And you cannot verify what happens in jurisdictions where the provider might be compelled to assist without being permitted to disclose that assistance.

The honest version of a no-logs claim is something like: our servers are not configured to retain connection or traffic logs, and an independent audit has verified that configuration at a point in time. That's meaningful. It's just not the same as a mathematical guarantee of privacy.

When providers have been subpoenaed or faced law enforcement requests, the cases where they've been unable to produce logs are genuinely informative. Several providers have pointed to specific legal proceedings where they had nothing to hand over. Those cases matter more than any marketing claim, because they're real-world tests. They're also rare, and they reflect the situation at the time of the request, not necessarily the current architecture.

Practical takeaway: When you read a no-logs policy, look for specificity. Which categories of data are excluded? What is retained for billing or abuse prevention? A policy that answers those questions precisely is more credible than one that simply repeats the phrase.

Reading an audit like an engineer: scope, date, firm, findings

Providers increasingly commission independent audits and publish the results, or summaries of them. This is genuinely positive. An audit is more meaningful than a self-certification. But audits vary enormously in what they actually cover, and a badge saying "independently audited" tells you almost nothing without the underlying report.

Scope

The single most important question is what the audit actually examined. Common scopes include: the VPN client application (looking for vulnerabilities in the software itself), the server infrastructure configuration (checking whether logging is disabled as claimed), the no-logs policy implementation (verifying that server configuration matches the stated policy), and cryptographic implementation review (checking that the protocol is implemented correctly).

These are different things. An application security audit tells you the client isn't sending your data somewhere unexpected. It doesn't tell you whether the servers log your connections. A no-logs audit tells you the servers aren't logging at the time of the audit. It doesn't tell you about the application. Knowing which of these a provider has commissioned, and which they haven't, is informative in itself.

Date

Infrastructure changes. A 2019 audit of a provider's server configuration tells you very little about their current setup, especially if they've migrated infrastructure, changed data centre providers, or significantly updated their software stack since then. Audits that are more than two years old should be treated with scepticism unless there's a clear statement that the architecture hasn't materially changed and a more recent partial review has been conducted.

Some providers now commission annual audits. That cadence is more credible than a one-time exercise.

Firm

The auditing firm's reputation and independence matter. Firms that specialise in security auditing and have a public track record of finding and reporting genuine issues are more credible than general consultancies with no public security research history. The key question is whether the firm has any ongoing commercial relationship with the provider beyond the audit itself, and whether the engagement terms allowed the firm to report findings without provider approval.

Some providers publish the full audit report. Others publish a summary prepared by the provider. These are not the same thing. A full report, including findings that were remediated before publication, gives you a much clearer picture of the provider's actual security posture than a curated summary.

Findings

A clean audit with no findings is not automatically more credible than one with findings that were subsequently fixed. In fact, an audit that reports nothing at all is sometimes a sign that the scope was narrow or the review was superficial. Real security reviews of complex infrastructure tend to find something. The meaningful question is whether findings were material, whether they were remediated, and whether the provider disclosed them openly.

Practical takeaway: Find the actual audit report, not the provider's blog post about it. Check the scope section. Check the date. If the provider only links to a summary, that's a data point too.

Jurisdiction: where legal process actually reaches

Jurisdiction is the part of VPN evaluation that gets the most dramatic treatment in marketing and the least rigorous treatment in practice. The reality is more nuanced than either "five eyes bad" or "offshore incorporation means you're safe."

A provider incorporated in a jurisdiction outside the UK or EU is not beyond the reach of legal process. What jurisdiction determines is which country's courts and agencies can compel the provider directly, and under what procedural rules. A provider incorporated in, say, the British Virgin Islands can still be served with requests through mutual legal assistance treaties. It can still be subject to informal pressure. And if it has infrastructure, staff, or business relationships in countries with stronger legal reach, those touch points create exposure.

The relevant UK framework is worth understanding. The Investigatory Powers Act 2016, sometimes called the Snoopers' Charter, gives UK authorities broad powers to compel communications providers to retain and disclose data, and to do so covertly. Whether a foreign-incorporated VPN provider falls within the Act's reach depends on whether they're deemed to be providing services to UK users and whether they have a UK presence. The Act and its codes of practice are publicly available, and the legal position for foreign providers is genuinely contested in some cases.

The "fourteen eyes" framing, which refers to intelligence-sharing arrangements between a group of countries including the UK, US, Australia, Canada and several European states, is real in the sense that those arrangements exist and that intelligence shared under them can be used domestically. It's less useful as a provider-selection criterion than it might appear, because the arrangements primarily concern signals intelligence rather than routine law enforcement requests, and because a provider in a non-member country is still subject to that country's own laws, which may be considerably less protective.

What jurisdiction does tell you, concretely, is which country's data retention laws the provider must comply with. The EU's Court of Justice struck down the EU Data Retention Directive, and member states have had varying approaches since. The UK retained its own data retention framework post-Brexit. A provider subject to UK law faces different mandatory retention obligations than one subject to Swiss or Icelandic law. Those differences are documentable and worth checking.

The NCSC's guidance on device and network security doesn't specifically address consumer VPN jurisdiction, but its broader framing on supply chain trust is applicable: the question isn't just whether a provider is incorporated somewhere convenient, but whether you can verify their claims about what they do and don't retain.

Practical takeaway: Look up the provider's jurisdiction and check what data retention obligations apply there. Don't rely solely on the provider's characterisation of their own legal environment.

RAM-only servers and other verifiable architecture claims

RAM-only or diskless server architecture is a claim several providers now make, and it's worth understanding what it does and doesn't guarantee.

A server that runs entirely from RAM, with no persistent storage, loses all its state when powered off or rebooted. If a server is seized by law enforcement, there's nothing on disk to image. That's the genuine benefit. It makes forensic recovery of historical connection data much harder, assuming the provider isn't logging to a remote database (which would persist independently of the server's local state).

The limitations are equally concrete. RAM-only architecture doesn't prevent real-time logging to a remote endpoint. It doesn't prevent a provider from being compelled to begin logging prospectively before any seizure occurs. And verifying the claim is genuinely difficult from outside: you're largely trusting the provider's description of their infrastructure, plus whatever an audit has confirmed.

Some providers have had their infrastructure seized and been able to demonstrate that nothing recoverable was obtained. Those cases are the closest thing to a real-world test of the claim. They're worth looking for in a provider's public history.

Other architecture claims that appear in provider marketing include multi-hop or double-VPN routing (your traffic passes through two servers in sequence, so neither server has both your real IP and your destination), and obfuscation layers that disguise VPN traffic as ordinary HTTPS. Multi-hop does provide a genuine additional layer of separation, at the cost of latency. Obfuscation is a practical tool in specific contexts, particularly where VPN traffic is actively blocked, but it doesn't change the underlying privacy properties of the connection.

Practical takeaway: When a provider makes an architecture claim, ask whether an audit has specifically verified it, and whether there are any real-world cases that have tested it. Marketing copy and verified architecture are different things.

What a VPN cannot do, stated without hedging

This is the section that matters most for calibrating expectations, and it deserves directness.

Browser fingerprinting

Your browser exposes a detailed profile of itself to every site you visit: your user agent string, installed fonts, screen resolution, timezone, supported APIs, WebGL renderer, and dozens of other attributes. Taken together, these form a fingerprint that can identify your browser across sessions and across IP addresses. A VPN changes your IP. It does nothing to your browser fingerprint. The Electronic Frontier Foundation's Cover Your Tracks tool demonstrates this concretely.

Logged-in tracking

If you're signed into Google, Facebook, or any other service, that service knows who you are regardless of your IP address. Your account is the identifier. A VPN doesn't change that. This is a point that gets elided in a lot of VPN marketing, which conflates IP-based tracking with identity-based tracking. They're different mechanisms and require different mitigations.

Endpoint security

A VPN encrypts the tunnel between your device and the provider's server. It has no effect on what happens on your device. Malware running on your machine can observe your traffic before it enters the tunnel, log your keystrokes, or exfiltrate data entirely outside the VPN connection. This is not a VPN problem to solve; it's an endpoint security problem. The two threat models don't overlap.

The destination server

Whatever the destination server logs, it logs. If you visit a site over HTTPS through a VPN, the site sees a request from the VPN server's IP. It still logs that request. If the site is operated by someone who wants to track you and you've given them identifying information, they have it. The VPN protects the transit path, not the endpoints.

End-to-end encryption is a different thing

VPN tunnelling and end-to-end encryption are architecturally distinct. A VPN encrypts traffic between you and the VPN server. E2EE, as used in messaging applications, encrypts content such that only the intended recipient can read it, and the service provider cannot. If you want to understand what E2EE does and doesn't protect, that's covered separately in the piece on what end-to-end encryption actually protects. Using both doesn't make either redundant; they address different points in the chain.

Correlation attacks

If an adversary can observe both your connection to the VPN server and the VPN server's outbound connections, they can potentially correlate timing and volume to identify which sessions belong to you. This is a known limitation of VPNs and of anonymising networks generally. For most threat models, this is theoretical. For high-risk users facing well-resourced adversaries, it's a concrete concern that a VPN alone doesn't address.

Practical takeaway: Map your actual threat model before choosing tools. A VPN is the right answer to a specific set of problems. For the problems it doesn't address, identify what does, rather than assuming the VPN covers them.

Putting the evaluation together

The evaluation framework that emerges from all of this is fairly compact. For any provider you're seriously considering, you want answers to a small number of concrete questions.

• Which protocols do they offer, and what are the defaults? Is the protocol open and documented, or proprietary?
• What does their privacy policy say, specifically, about which categories of data they retain and for how long?
• Have they published audit reports, not summaries? What was the scope, who conducted the review, and when?
• What jurisdiction are they incorporated in, and what data retention obligations apply there?
• Have they ever faced a legal request? What did they produce, or fail to produce?
• Do they make architecture claims (RAM-only, multi-hop) and is there verification beyond their own documentation?

None of these questions will give you certainty. That's not the goal. The goal is to replace marketing claims with verifiable facts where facts exist, and to be honest with yourself about where you're extending trust. A provider who answers most of these questions with specific, verifiable information is in a different category from one whose answers are marketing copy. That distinction is something you can assess yourself, without needing a recommendation from anyone.