[tor-dev] Should popularity-hiding be a security property of hidden services?

Paul Syverson paul.syverson at nrl.navy.mil
Thu Apr 16 04:16:12 UTC 2015

Hi George,

Thanks for taking up the challenge I raised to you of coming up with
use cases where leaking popularity is a threat.

Perhaps others have suggested that we don't worry about popularity at
all, but for the arguments I had been trying to make these are straw
men. I don't suggest that we completely ignore popularity.  As one
simple example, if you monitored and published the popularity of onion
services at the level of seconds or minutes (maybe even courser)
adversaries could almost certainly construct practical intersection
attacks on users of some onion services whose client-side traffic was
being monitored. 

You noted anonymity is not binary, but you have only addressed
popularity at a binary level: protect it or ignore it. We have an
unfortunate tendency to sometimes do this in the Tor design
community. For example, any design choice that partitions (or more
generally statistically separates in any way) clients by the portions
of the network about which they've been given information is not even
worthy of consideration because partitioning is just bad. On the other
hand, some pseudonymous profiling by exits is simply acceptable
because of practicality considerations (and indeed, time to keep
opening new connections on existing circuits has recently been
significantly increased in Tor Browser Bundle for usability
reasons---with a bit of discussion, but no significant analysis and no
Tor Proposal). These are just single examples on each side for
contrast, but others are easy to produce. I don't want to get into
addressing the problem of this tendency in general here, I just want
to make sure that we avoid specifically doing that for this problem.

I think I mentioned to you previously the sorts of popularity
statistics I would like to gather. But perhaps I was unclear. I'll set
it out here publicly for others to comment on. Details might change,
and of course we'd have to worry about particular protocols. That's no
different than anything else in Torland.  But I want to assume that
something like the following is basically feasible.  As an argument
from authority, I talked to Aaron a bit about how you might do this
and we were both convinced it should be feasible to do this securely.

So, assume we have an onion service statistics gathering protocol that
outputs say weekly the number of connections and bandwidth carried by
the highest 5 percent, then 10 percent, then 20 percent, then 40
percent, then bottom 60 percent of onion services.  I take it as given
that these would be useful for many reasons, some of which you
cited. We can revisit usefulness as needed.

The question I would like to have answered is what sort of practical
threat could be posed by leaks from this. One could imagine an active
attacker that hugely fluctuates the volume of a given onion service to
determine which bin it had been in assuming very generously that this
isn't covered by noise of other onion services or a very long attack
on a service whose volume does not otherwise change.

These statistics are not a threat in the parkour example. They do
not reveal historical volumes of individual onion sites.

In the dystopian future scenario, the authorities know which hidden
services are run by the rebels but not which ones are popular, and
they want to take down the popular ones quickly since the revolution
is imminent. If they happen to guess the right few they could inflate
the activity (if they can access the onion site) and learn in a week
that they were popular (assuming that they are lucky enough to be sure
that, e.g., noise doesn't obscure that). This is a pretty iffy and low
bang for the buck attack. As a contrasting example, authorities could
easily locate the the guard(s) of targeted onion sites (we're assuming
they can access targeted onionsites) via congestion attacks and then
just monitor the network activity from the guard or its ISP to see the
popularity of targeted onionsites in realtime. Not to mention
deanonymizing anyone they are watching on the client side. This could
be done faster, easier, and more productively than using the

Tor is full of security vs. performance and/or efficiency and/or usability
trade-offs. If we're going to rule out any onion service popularity
statistics, I'd like some indication of a realistic potential threat.
So far I don't feel I've heard that.


More information about the tor-dev mailing list