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 statistics.
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.
aloha, Paul