What a "no logs" claim can and cannot mean

There are two quite different claims hiding under one phrase. The first is a policy. The provider's systems could record something, and they've been configured not to.

The second is structural. The provider's design means the data doesn't exist in a form anyone could hand over. That holds even under compulsion, and even if the people running it changed their minds tomorrow.

The second is worth far more, and the sentence in a policy rarely tells you which of the two is on offer. A policy can be amended, misapplied or overridden by whoever holds the root credentials. It survives only as long as the current owners and the current legal position do.

A structural limit holds regardless of intent. End-to-end messaging is the familiar analogy. A provider that can't read your message contents is in a different position from one that has decided not to look.

Connection metadata is the hardest of these categories to be structurally incapable of holding. It's worth understanding why before you hold it against any provider. A provider has to authenticate paying accounts, know which exit a device may use, bill for it, and notice when a node is failing.

Each of those jobs is a reason for an account identifier and a timestamp to meet somewhere. Say you open a VPN app and pick an exit. Before the tunnel comes up, something has to check that your account may use that exit, and the check happens at a particular moment.

When a claim is vague, it's usually being made about the first category and read as though it were about all of them. Separating them is most of the work.

This is the gap worth noticing. Suppose a policy discards contents, destinations and DNS queries, and keeps connection metadata and billing records. It can be described as no logs, and the description isn't strictly false.

So what does it leave out? That the remaining records can still show a particular paying account was connected to a particular exit between two particular times.

Whether that matters depends on what you're worried about. Against a hotel network, a mobile operator or an advertising intermediary building a profile from DNS lookups, it matters hardly at all. None of them sees the provider's records.

Now say you're worried about a party who can compel the provider, and who already holds a time and an exit address to correlate against. For them, connection metadata is the informative part. It's exactly what the reassuring phrase wasn't addressing.

A VPN exit is a relay. Say you load a page. A packet arrives from your device inside an encrypted tunnel, the server decrypts the outer layer, and it sends the contents onward to the destination address written in the header.

It can't do that without reading the address. The same applies in reverse for the reply. That's no weakness in a particular implementation. It's what forwarding is, and no policy, protocol or jurisdiction alters it.

So what's the honest framing of a no-logs position? The provider knows where your traffic went at the moment it forwarded it. It doesn't write that down.

That distinction does a lot of work. Momentary handling leaves nothing behind once the packet has moved on. A written record persists, can be searched and can be demanded.

So encryption relocates trust. It doesn't remove it. Your local network loses its view and the exit operator gains one. The question to ask is what gets persisted, not what's seen in passing.

Our connection service writes one row when your device connects and one when it disconnects. Each row carries an account identifier, a timestamp, the event type, a status, the exit used, the platform and the client version. The disconnect row also records how long the session lasted, and a row can carry an error message, a session ID and a disconnect reason.

Each row also carries a session identifier that ties a connect to its matching disconnect. Where something failed, there's an error detail and a reason. That's the shape of the table.

Say you connect to Tokyo at 9:00 and disconnect at 9:40. That's two rows, tied together by one session identifier. Between them they hold your account identifier, the Tokyo exit, the two times and the 40-minute duration. The event type, status, platform and client version are on each row too.

Those rows have no column for browsing activity, destination addresses or DNS queries. That's true of that table. It isn't the whole picture.

Here's the rest. Every node runs a permanent packet capture on the tunnel interface, and a second one on DNS traffic. We use them to build usage figures.

Once an hour, a node turns its capture into an aggregate and sends it to our usage warehouse. For each client it holds totals of its TCP traffic, the outside addresses it reached over TCP, the country, city and network of each one, and the domains matched to those addresses. Traffic over UDP, which includes HTTP/3, isn't in it, and neither is the Android app's AmneziaWG mode.

The aggregate isn't keyed to your account. It's keyed to the 10.x address your device is given inside the tunnel. But each node names those addresses by account and device, so the aggregate can be linked to your account.

The domain list is inferred, not a record of your own lookups. Each hour, the node maps every plain DNS answer it sees, from any device on it, to the addresses in that answer. Then it labels the outside addresses your tunnel address reached with those names. Encrypted DNS keeps your own lookups out of the capture, but a name can still land on your row if anyone else on that node looked up the same address. Partial isn't the same as absent.

Clean Web is part of the same story. When it's on, it refuses known ad and tracker hostnames at name resolution, and the resolver on each node runs with its own query log switched off. That doesn't hide your lookups from us, because the capture sees the same queries on the node. The app shows you a running Blocked counter. It doesn't show you a list of names.

Your originating public address is stored as well. It's saved 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, all tied to your account.

One detail is easy to blur, so here it is precisely. The usage warehouse has a field named client_ip. That's the 10.x tunnel address. It isn't the address your connection comes from, which lives with the session token and in the sign-in records.

So what can our records show? That your account connected to a particular exit, when, for how long, and on what platform. Through the usage aggregate, they can also show which outside addresses and domains a tunnel address reached in a given hour. On top of that there's a record of each device, a log of each sign-in with the address it came from, and the analytics our apps send to Google's Firebase under your account ID. If you're weighing us up, assume all of that is available.

Three things here deserve to be held against us, and we won't explain them away. The first is the capture itself. Our nodes record enough to say which outside addresses and domains a tunnel address reached each hour. A service that can't produce that is in a stronger position than one that can, and we can.

The second is retention. Our connection table has no automatic purge, so rows written for diagnostics stay until something deletes them. The usage aggregate is different: our warehouse drops it after 90 days. That's a setting today, and we could change it. A provider that discards this data after a short, published window is stronger on this axis. If that's decisive for you, you should prefer that provider.

The third concerns key material. In our flow, the server issues the tunnel configuration, and that configuration includes the private key. Your device doesn't generate its own key pair and keep the private half locally.

A design where the client generates its own pair can say the private half never leaves the device. Ours can't, and the opposite is closer to the truth.

It's a defensible arrangement. It's what lets our apps configure a tunnel without key generation on the client. But if you're comparing designs, you should know which one you're looking at.

Set against that, there's one thing we can say cleanly. We can't read the contents of your HTTPS traffic. Destinations and DNS are a different matter, as you've just read.

If you weigh these three problems more heavily and go elsewhere, you're reading the facts correctly. That's the point of listing them.

An independent audit is better than no audit. It's also weaker evidence than its usual presentation suggests.

An auditor examines the systems made available to them, at a point in time, against a scope the provider agreed to. A clean result says that during that window, on that scope, the described practice matched the stated one.

It doesn't establish what happens in the months afterwards, what sat outside the scope, or what a later operator would do with the same infrastructure. It doesn't usually reach the upstream providers whose hardware the exits run on, either.

Suppose the scope covered a provider's exit servers and left out its account database. A clean result tells you nothing about the account database.

The questions you should ask are narrow. Who performed it? What was in scope? Is the full report published, and how old is it? An audit whose scope is unpublished is close to uninformative, because the scope is where the interesting choices live.

A great deal of marketing rests on where a company is registered. It's usually phrased as being outside any mandatory data retention regime. Here's the limitation. The absence of a law requiring retention isn't, by itself, the presence of one forbidding disclosure.

A provider in such a place is free not to keep records. It's generally not immune to a request for whatever it does keep. And it may operate exit servers in countries whose rules differ from its own.

The infrastructure tends to go unmentioned. Exits sit in data centres run by other companies. Suppose a provider is registered in one country and its exit stands in another. The rules that reach that building are generally the rules of the place it stands in.

So jurisdiction is worth something as context and little as a guarantee. A short, specific statement of which records exist tells you more than a long one about where a company is incorporated.

The pattern that holds up is specificity. A provider that enumerates its records is making a statement that can be falsified, and that's a meaningful thing to offer. One that asserts a quality, such as private, anonymous or zero-knowledge, is making a statement that can't be checked at all.

So when you read any policy, including ours, ask the questions below. They're the ones that separate the two.