What "no logs" can and cannot promise
“No logs” is the most repeated sentence in this industry and the least defined. Every provider says it; almost none of them tell you what the exceptions are, and a policy that hides a meter is worse than one that explains it.
So this is the whole list — the one already published, with the reasoning attached, on what we log.
What is not recorded
- Browsing history. Not recorded.
- The DNS names you resolve. Not recorded — on any tier. The resolver runs with its query log disabled and its statistics disabled.
- Traffic content. Encrypted end to end. We carry it and cannot read it.
- Your ISP-assigned address, in connection with your account.
- Connection times. No record of when you connected or disconnected.
- Your device’s real network.
What is recorded, and why
Four rows. Not because four is a nice number, but because each one is something the service cannot run without:
| Data | Why it exists | Retention |
|---|---|---|
| Email address, password hash | your account | life of the account |
| Subscription and payment record | billing; card details are Stripe’s and never reach us | life of the account |
| Device records — name, tier, tunnel IP, your public key | to provision and revoke access. Configuration, not activity | life of the account |
| Aggregate data-volume counters | to keep the service fast and fair, and to stop abuse. Byte counts only: no destinations, no DNS, no browsing | currently up to 30 days, per device |
Plus one that arrived recently and is worth naming because it is unusual: the speed test results you run yourself from the portal — two rates, byte counts, latency, and which of your own devices you labelled the test with. The five newest per account, pruned as new ones arrive. It is the result that was on your screen and nothing about the transfer behind it: no address at either end, no destination.
On the counters. The counters show how much you transferred, not what. A byte total cannot be turned back into a browsing history, and it is never combined with destination data because there is no destination data to combine it with. It is disclosed for the same reason every row is: a meter you are not told about is a meter you cannot argue with.
Server logs. Ordinary operating-system logs — service starts and stops, crashes, errors, deployments. Kept for 14 days, asserted by the automated audit to contain no customer traffic or DNS data and no client-tier addresses.
How the claim is tested rather than asserted
This is the part that separates a policy from a promise:
- A real query is sent, then the system checks that nothing was written. A DNS query goes through each resolver; the check then requires that no log appeared. A canary name — one that cannot occur by accident — is injected for the same purpose, so “we found nothing” cannot be an artifact of looking in the wrong place.
- The result is signed and published, daily. Each host signs a
machine-readable report with a detached ed25519 signature; the site’s build
verifies those signatures with stock
ssh-keygenand refuses to render if one fails. The mechanism, and how to fetch and check it yourself, is on the audit page. - A failure is published, not hidden. A failing check still writes and signs the report first, then the unit fails — so a violated report exists at its URL and stays there.
- The infrastructure is declarative and version-controlled. Nothing is hand-edited on a running machine; what is published is what runs.
The warrant canary is not published yet
The policy commits to a signed, periodically renewed warrant canary at a stable address, recording how many disclosure demands have been received. It is not published yet. Saying so is the point: a commitment listed next to things that are already true, without a marker for which is which, is how “we’ve added X” quietly becomes “we said we have X”. When it exists, it will be linked from what we log; until then, treat it as pending.
What a tunnel cannot protect you from
What a tunnel does not cover, in full:
- malware on your own device — a tunnel is not an antivirus;
- logging in to an account that knows who you are — Google still knows which Google account you used;
- a browser using its own DNS in a way your device does not route through the
tunnel. This is a real bypass, which is why the
privacyandsecuritytiers put the resolver inside the tunnel and why the portal includes a leak test that reports where a freshly minted name actually went; - anything you do after you disconnect.
A VPN hides your traffic from the network you are on. It does not hide you from the services you deliberately log in to, and any provider that implies otherwise is selling you a feeling.