When a VPN Says It Can't Log
Obscura's Hacker News submission claims the VPN can't log your activity. That's a different statement from the usual no-logs promise: one is policy, the other is architecture. What such claims require, what audits can and can't show, and what to ask instead.
The verb is doing the work
A submission titled “Obscura: VPN that can’t log your activity” reached Hacker News, drawing 121 points and 94 comments. The technical explanation sits in the FAQ at obscura.com. The interesting word is “can’t.” Most VPNs say they don’t keep logs. Obscura says it can’t. That difference is not cosmetic — it moves the argument from a promise to a property of the system. Discussions that follow claims like this tend to be less about the product than about the standard we’re willing to apply to it.
A promise can be changed. A property has to be built.
A no-logs policy is a statement about intent. It can be sincere and still be temporary: a company doesn’t retain connection timestamps today, changes its privacy terms next quarter, and starts retaining them. Users generally have no way to notice, because logs are not visible to them in the first place. For a user, the practical distinction is blunt — a policy can only be trusted, while a property can at least be tested.
“Can’t log” is a claim about the machine. Making it true means removing the places where records pile up. Session state lives in memory rather than on disk, so a reboot erases it. Keys are held for the duration of a session rather than written down. Account and billing data are kept as far as possible from individual sessions. DNS resolution doesn’t leave a trail of its own. Support tickets and debugging don’t quietly write logs that can be matched to a timestamp. Miss any one of those, and “can’t” slides back to “don’t.”
There’s a limit to what a single link establishes. What the source supports is narrow: the claim is made prominently, and a technical FAQ is offered. Which of these properties Obscura actually implements is something the FAQ has to be read against, not assumed.
What an audit can and cannot show
Third-party audits are the usual backing for this kind of claim, and they vary more than the marketing implies. Some verify that the written policy matches the live configuration. Others go into the data center: inspect the servers, watch the boot process, check whether persistent storage exists. The first kind barely supports a strong “can’t log” claim. The second is what you would actually want to see. A report with a narrow scope can still be marketed as “audited,” which is why the scope line matters more than the badge.
Timing matters, too. An audit is a snapshot. Hardware gets replaced, deployments change, and a report from two years ago may describe a system that no longer exists. Jurisdiction is a related variable: if a provider operates somewhere that can compel it to start retaining data, or to alter its infrastructure, then “can’t” has an external dependency that no amount of clean architecture removes.
There is also a subtler link to consider. Even when message content is never written down, connection metadata — what time, which account, which exit IP, how much traffic — can be enough to tie a person to a session. So the question isn’t only whether content is logged. It’s whether anything durable exists that could later be demanded.
Questions worth asking
Whether the claim is about policy or architecture. Whether there is an independent audit, what its scope covers, and how recent it is. Whether servers hold anything that survives a reboot. Whether accounts, payments, or support tickets can be joined to a specific session. Where the revenue comes from, since a free service still has to be paid for.
The 94 comments on the Hacker News thread are probably circling the same set of questions. Putting “can’t log” in a headline invites a harder standard than “don’t log,” and that is the right trade. It’s the only version of the claim a user can hold a provider to.