Clouds and onions

Hal Finney comments, correctly, that the story I told in Anonymous Three-Card Monte misses a couple of significant points. So here's an attempt to rectify that.

Generally, when you use an anonymizer, you talk to the anonymizer -- that is, to some set of hosts participating in the anonymizing. After several carefully managed intermediate steps the anonymizer -- that is, some participating host -- talks to the service you're really interested in. To that service, it looks like the request came from the IP address of that host, not yours, because that's indeed who's talking to it.

One way to look at this is to consider the anonymizer as a "cloud". You don't really know what goes on inside. An outside observer would see traffic between you and the cloud and between the cloud and the real service. It would also see a lot of random encrypted traffic among the hosts in the cloud, but as long as there are enough users (or at least computers spitting out random encrypted bits and pretending to be users) for the "I'm Spartacus" effect to kick in, that outside observer can't connect the you to your real service.

Good anonymizers use multiple hops inside the cloud, each of which is unaware of the rest of the chain, to provide multiple layers of protection, like layers of an onion.

The hosts, called "exit nodes", that talk to real services have to use their own IP addresses. Because of this, an outside observer could say "at such and such time, someone at this IP address connected to this Very Bad Site." If you're just using the anonymizer, but not participating in the cloud, there's zero chance that your IP address will be connected directly to the Very Bad Site. In effect, the exit nodes have collectively taken on that particular risk for you.

On the other hand, if you're using an anonymizer, you should probably pessimistically assume that an outside observer could tell which hosts are in the cloud. That is, you should assume that people can tell you're using the service. You should also take care that you use an encrypted connection to your real service. The exit node can only do what you (indirectly) ask it to, and if you don't ask it to use encryption, someone watching could say "I don't know who's at the other end of this connection, but whoever it was logged into this Very Bad Site under the name of ..." Caveat browsor.

So where does that leave the original story?

Well, IP addresses are being pooled, but among exit nodes, not among exit nodes and users. If you're an exit node, your IP address will be directly associated with the activity of random people whom, if the system is working, you have no way of identifying. This means you may have some explaining to do, more or less as described in the punchline. And you may have less explaining to do if your node has an IP address from a country that doesn't keep close track of who's using what address. Assuming there are such.

If you're running an anonymizer and not charging money for it, you might consider requiring anyone who uses the service to be prepared to host an exit node as well [It's not clear how you'd convince someone they wanted to do that. See this later post, for example.]. This, arguably, distributes the risk fairly. As a corollary, it also produces the "big pot of IP addresses" scenario that I originally described.

However, if you're just using such a service and not acting as an exit node, you shouldn't have to explain much more than why you're using an anonymizer. Beyond that, you can shoot yourself in the foot in a variety of ways, whether by failing to encrypt your connection to your real service, or by giving away more information than you think you are, or confiding in someone who turns out not to be who you thought they were or by some similar mistake. But the anonymizer can't help you there.

The larger point here is that you should be good and sure you understand what an anonymizer can and cannot do before you decide to use one.