Tor Exit-Relay Transparency in 2026: Auditing Which Operators Log What

Every few months a new “exit relay audit” makes the rounds on the privacy mailing lists. Someone scrapes a list of exit IPs, pulls the WHOIS, pings each one, and publishes a spreadsheet with a column labeled “logs?” filled in by guesswork. The spreadsheet is almost always wrong. Not because the author is lazy, but because the question it asks is ill-posed. There is no single “logs or doesn’t log” flag you can read off a relay. There are at least four different logging surfaces, and the operator’s privacy policy usually covers only one of them.

So let me be blunt about the method before getting into specific relays. A Tor exit node is a box sitting between the encrypted Tor circuit and the open internet. The operator controls the box, the OS, the network uplink, the billing provider, and the physical host if they rent. Any of those layers can observe traffic. Whether the operator chooses to record what they observe is a policy question. Whether the operator can record it is a hardware and topology question. Both matter, and neither is documented publicly in the way researchers keep hoping.

What an exit relay actually sees

Start with the mechanism. In onion routing, the exit node is the last hop in a three-node circuit. It peels the final encryption layer and forwards the plaintext (or the still-TLS-wrapped ciphertext, depending on the destination) to the target server. The exit knows the destination but not the source. It sees no user IP address, because that was stripped by the guard and middle relays two hops back.

What it does see, per the standard explanation of onion routing: the destination host, the timing and volume of the connection, and the payload if the user failed to use HTTPS. If the destination uses HTTPS, the exit sees a TLS handshake and encrypted bytes. If the destination is plain HTTP, the exit sees everything the user and server exchange. That is not a logging policy question. That is the protocol working as designed.

The important consequence for a transparency audit is this: an exit relay operator who swears up and down that they log nothing is making a claim about their software configuration and retention habits, not a claim about what their hardware is physically capable of observing. Anyone with root on that box can run tcpdump. The privacy policy is a promise, not an architectural guarantee.

The four logging surfaces nobody audits separately

When I dig into an exit operator’s claims, I split the question into four parts. Most public audits collapse them into one and get a meaningless answer.

• Application-layer logging. Tor itself has a configurable log level. An exit running Log notice file /var/log/tor/notices.log writes routine circuit events but not user traffic. A relay running Log debug writes far more, including connection-level detail. This is the surface most operators actually control.
• Network capture. Anything on the host, from tcpdump to a full IDS, that records packets. Rarely disclosed. Sometimes present for abuse-handling reasons, which is the honest excuse operators give.
• Upstream provider logs. If the relay sits on a VPS, the hosting provider logs flow data, often for billing and abuse purposes, and often retains it for months. The operator may genuinely not control this and may genuinely not know the retention window.
• Abuse-response records. When a relay gets a DMCA notice or a law-enforcement request, the operator’s mailbox becomes a logging surface. Whatever they type in reply, and whatever they saved to answer it, is now a record.

An operator can be honest on surface one, negligent on surface two, blind on surface three, and chatty on surface four, all in the same month. Reading only their privacy page tells you about surface one.

Why “no logs” policies are cheap to write and hard to verify

Look at how a real privacy policy handles this. Lantern, which is a circumvention tool rather than a Tor exit relay but makes the same class of promises, states that its servers do not and never will log connection timestamps, browsing history, traffic destination, DNS queries, or any link between an account and a real identity. It also states the design principle behind the promise: the systems are built so that even under compulsion, the company cannot hand over data it does not possess.

That last sentence is the only kind of “no logs” claim worth taking seriously. It is a negative capability argument. The operator is saying the architecture prevents the data from existing, not that policy discourages collecting it.

Most exit relays cannot make that argument. A relay is a general-purpose server forwarding arbitrary traffic. It has no way to architecturally self-restrict the way a purpose-built proxy might. The honest claim from an exit operator is “I have configured logging minimally and I delete what accumulates.” The dishonest claim, or at least the misleading one, is “I cannot log.”

I have seen both. The ones making the second claim tend to get hostile when you ask for the retention window.

What you can actually audit from outside

You cannot read the relay’s filesystem. Full stop. Any audit that pretends otherwise is theater. What you can do is assemble circumstantial evidence and cross-check it against the operator’s stated policy for contradictions.

Things that are checkable without access:

• Log directives in the Tor config. If the operator publishes their torrc, read the Log lines. Many do publish it, and the difference between Log notice and Log debug is a real signal.
• Abuse mailbox behavior. Send a polite, non-adversarial query about how the operator handles notices. Response time, whether they cite a specific policy, whether they forward the notice to a lawyer, all of that tells you more than a privacy page.
• Hosting provider disclosure. If the operator names their upstream, you can read that provider’s own privacy and retention terms independently. A relay on a provider with aggressive flow-log retention inherits that retention whether the operator likes it or not.
• Consistency over time. An operator whose privacy page changed in the last two years, or whose relay’s ASN changed, warrants a fresh look. Old audit results go stale.

What you cannot check: whether they ran tcpdump last Tuesday, whether they complied with a subpoena last month, or whether they have a second logging box in the rack that they forgot to mention.

The law-enforcement angle, stated plainly

The reason this matters is not theoretical. Exit relays are the visible edge of the network, and they attract attention because they are the easiest place to send a letter. The relay operator is often a volunteer with no legal budget, and the letter arrives at their personal email.

There is a real asymmetry here that both sides of the debate tend to obscure. Law enforcement would prefer operators who log everything, because a logged relay is a data source. Privacy advocates would prefer operators who log nothing, because an unlogged relay is a dead end. The operator is caught between a policy they wrote and a legal request they did not anticipate. Every audit I have seen ignores this tension, which is strange, because it is the whole story.

So my working assumption when reading an audit is this: assume the operator’s stated policy is accurate for the log they control, and assume it says nothing about the logs they do not control. Then ask what is on the box that they did not think to mention.

Where this leaves the practical researcher

If you are evaluating exit relays as part of a threat model, stop looking for a clean “logs / no logs” label. It does not exist. Instead, treat the exit as a known observer of destination and timing, assume any plaintext protocol leaked through it is fully visible, and apply the same discipline the general Tor guidance recommends: do not send personally identifying material over the network regardless of what the exit operator claims.

For the operators reading this: publish your torrc. Publish your retention window in days. Publish your abuse-response policy. Those three disclosures do more for transparency than any privacy page written in careful legalese. And for the auditors: stop scoring relays on a single column. Split the question into the four surfaces, mark the ones you cannot check as unknown, and stop pretending unknown means clean.

Research only. Nothing here is operational guidance for using any specific network, and I have deliberately not named live relays or provided access instructions.