How to judge a VPN, including this one

The protocol is the one technical answer worth insisting on. The rest of the product sits on top of it.

A current answer is WireGuard. It fixes its cryptographic choices in advance, so there's nothing to negotiate. Its handshake is a single round trip. And it's deliberately small, which is what makes it feasible at all to read the implementation, not the marketing.

What about a provider that leads with an in-house protocol nobody outside the company has examined? That's a larger claim with less to check it against.

Once the protocol is named, questions about encryption strength have almost no information left in them. 'Military-grade encryption' has no technical content.

The primitives involved are the ordinary ones already carrying banking, messaging and everyday web traffic. You have no way to turn the phrase into a difference between two products. A provider that spends its most prominent space on something that distinguishes nothing has told you where its attention goes.

We use WireGuard. So does anyone else who answers this question with a current protocol. Say you're comparing us with one of them. Read honestly, this line is a tie, and we don't get to count it as a win.

A VPN moves the point where your traffic enters the public internet. That point is a machine the provider operates. So by construction, the provider is positioned to observe which addresses it forwards to on your behalf.

No policy changes that. A policy only governs what's done with the position.

This split is what most comparison tables miss. A claim about visibility is a claim about architecture, and you can reason about it from first principles. A claim about retention is a claim about behaviour. You can't check it from outside at all.

The same goes for name resolution. Clean Web, a switch in the app, sends your lookups to our own resolver, which refuses known ad and tracker hosts, so no socket is opened. It starts on in the Android app and off on iPhone, iPad, Mac and Windows. With it off, your lookups go through the tunnel to a public resolver instead.

For example, say an app on your phone asks for a known tracker's hostname. The resolver refuses, and no connection is made. That's a real benefit at the network level. It also means the resolver is a component with a view.

Both things are true at once. A provider that tells you only the first half is selling.

'No logs' is an adjective. The useful question is which fields exist in the database.

A provider that answers specifically has described something that could be contradicted. A provider that answers with reassurance hasn't. A good answer names what's stored, what's kept for billing, and how long the rest survives.

Here's ours. We write one row per connect and one per disconnect. Each holds an account identifier, a timestamp, the event type and status, which exit was used, the session duration, the platform and the client version. A row can also carry an error message, a session ID that pairs the connect with its disconnect, and a disconnect reason.

Suppose you connect to Frankfurt at 9:00 and disconnect at 9:40. That's two rows. Between them they record your account identifier, both times, each event's type and status, the Frankfurt exit, a 40-minute duration, your platform and your client version.

Those rows don't hold a destination, a visited site or a DNS query. They aren't the whole ledger, though. Our nodes run a permanent packet capture to build usage figures. Once an hour it becomes an aggregate that includes the outside addresses reached and the domains resolved.

That aggregate is keyed to the 10.x address we assign your device inside the tunnel, and each node names those addresses by account and device, so treat it as linked to your account. We keep it for 90 days. Your originating public address is stored too. It sits with the session token that keeps your app signed in, in a record we write each time you sign in, and in our API's request log. Your account holds your email, the name and photo your Apple or Google sign-in shares, and your plan. We keep a record of each device too: its name, platform, last exit and when it was last seen. And our apps send usage events and crash reports to Google's Firebase under your account ID. On Android and Windows, each session's summary includes the exit, duration, data used and tunnel address.

Part of what that specificity exposes is unflattering. There's no automatic purge on that table, so those rows sit on no retention clock. If your bar is 'nothing is kept', mark this against us.

So why publish the shape anyway? Because a vague claim can't be held to anything. A list of fields can.

Ownership is the cheapest thing to check and the most often skipped. Who is the operating company, and who owns it? The answer is usually several clicks away from the pricing page.

Shared ownership between brands isn't disqualifying in itself. Neither is a review site having a commercial relationship with what it ranks. Both are worth establishing before you treat two entries in a comparison as independent opinions.

Revenue matters more. Relaying traffic costs money continuously. Volume is billed at the exit, and each exit carries a monthly bill whether anyone routes through it or not.

A subscription bought inside an iPhone or Android app is processed by Apple or Google. They take a commission before the provider sees anything. So the headline price isn't the figure the provider works with.

Say you buy our monthly plan inside the iPhone app. Apple processes the payment and takes its commission first. What reaches us is less than the 3.99 US dollars you paid.

Where a service is free and unmetered, the arithmetic has to close some other way. The options are few: a bounded free tier whose cost is absorbed, a loss-leader funded by subscribers, or an arrangement in which the traffic itself has value to someone.

That's a constraint on every provider. It isn't an accusation about any of them.

A count is the easiest number to inflate and the hardest to use. Nobody connects to a fleet. Your session runs through one machine. So the question that bears on your experience is whether a well-provisioned exit sits near you or near the service you're reaching.

A total in the thousands, spread across dozens of countries, describes a cost structure. It leaves you no way to work out whether any of it helps.

So ask for the list. A provider willing to publish which cities it terminates traffic in has made a statement you can check against a traceroute. That statement becomes embarrassing if a location turns out to be an address block announced from somewhere else. A provider publishing only a total has kept the claim safely unfalsifiable.

Our list is short, and it changes as we add and retire servers, so the region list in the app is the one to trust. Naming exits is the easy part. The next section is where a short list stops looking good.

A short list is fine, and the shape of the gaps matters more than the total. Whole regions of the world have no exit of ours, so check the region list for the places you need before you pay.

Say you're in Dubai, Lagos, Mumbai or Toronto. Your nearest option is thousands of kilometres away, and a round trip pays that distance twice. No protocol removes the floor that distance sets.

On this line, a provider with a genuine nearby exit is the better purchase. If you're in one of those places, you should buy it.

We don't have a kill switch. If the tunnel drops, your traffic can continue over the ordinary network. Nothing holds it until the tunnel returns.

If you're browsing on a hotel network, that's an inconvenience. If you require that packets either go through the tunnel or go nowhere, it's a reason to choose something else.

Our server issues the configuration, and it includes the tunnel's private key. In a stronger design, the device generates its own key pair and sends only the public half. That design is stronger on exactly this axis, because the key material need not exist anywhere but the device.

We don't work that way. If you're ranking providers on key custody, rank us below those that do.

The surprise worth looking for isn't a hidden fee. It's a hidden second year: a headline monthly figure that turns out to be a long prepayment divided up. The rate it renews at is set out somewhere less prominent than the rate it starts at.

The test is simple. Find the renewal price before you pay, and treat its absence as the answer.

Read trials the same way, because copy tends to float a trial free of the plan it belongs to. Our seven-day trial attaches to the monthly plan and to that plan alone. The weekly plan and the day pass carry none.

Our prices are flat and don't step up: 1.99 US dollars a week and 3.99 a month, plus a 0.99 day pass on Android. Every plan reaches the whole region list with no device limit, and paid plans add unlimited session length.

Short plans are a worse business to run than annual ones. With a weekly plan, one acquisition cost is spread over a week. With an annual plan, it's spread over a year. That's part of why the annual plan is the one most pricing pages are built around.

A free tier is a good place to read a company's economics, because the limits are where the cost control lives. Hours cost money. Accounts don't.

A free tier capped in hours is being paid for by the cap. An unmetered one is being paid for by something the page hasn't mentioned.

So ask whether the published limits are the kind that would contain a bill. A speed cap degrades the experience without necessarily reducing total bytes. A device cap limits convenience, not volume. An hours cap maps directly onto the dominant variable cost.

We allow three free sessions a week, shared across all your devices. Each is a one-hour window that starts when you connect and keeps running if you disconnect, so three hours is the most you'll get. Every location is on the list, the same as on a paid plan.

Those limits are restrictive. The point is that they're legible. You can see what's given away and work out that it's affordable to give.

Several of the criteria that comparison tables lean on hardest carry no information at all. Cross them off. Your reading gets considerably shorter, and that makes room for the questions above. Those are fewer, and harder to answer with a logo.

You can't verify most of this checklist from a browser. Nobody outside a provider can inspect its database, watch its exit machines, or confirm a deletion happened.

Independent audits narrow the gap, and they're worth more than a self-description. But an audit is a point-in-time report on a scope the company chose and paid for. That isn't continuous proof.

That leaves a less satisfying but more usable criterion. Is a provider's account of itself specific enough to be wrong?

'We keep no logs' can't be contradicted by anything. A list of stored fields can. A country total can't be tested. Ten named cities can.

Specificity doesn't demonstrate honesty. It does create a way for dishonesty to be caught, and vagueness removes it.

Apply this consistently and it reorders the market. Some well-marketed providers become hard to evaluate at all, and some small ones become easy. It applies to this page too, including the lines above where our specific answer is the unfavourable one.