[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15254 [Tor]: Enable hidden-service statistics by default
#15254: Enable hidden-service statistics by default
-------------------------+-------------------------------------------------
Reporter: dgoulet | Owner:
Type: | Status: reopened
enhancement | Milestone: Tor: 0.2.7.x-final
Priority: major | Version:
Component: Tor | Keywords: SponsorR tor-hs stats
Resolution: | TorCoreTeam201509 PostFreeze027
Actual Points: | Parent ID:
Points: |
-------------------------+-------------------------------------------------
Comment (by asn):
OK, let me try to offer some rationale here.
Let me start by saying that IMO these stats are useful to us:
During the past months, I've used [https://metrics.torproject.org/hidserv-
rend-relayed-cells.html the HS bandwidth graph] ''many'' times when
talking to people to debunk the "darkweb iceberg" myth. I know that other
outreach people have used it the same way as well.
I've also found [https://metrics.torproject.org/hidserv-dir-onions-
seen.html the number of hidden services graph] useful for figuring out the
size of the onion space. For example, when we are discussing padding
techniques to defeat traffic fingerprinting for hidden services, we can
now calculate approximately what's the total overhead of the whole network
is going to be, since we know approximately the number of hidden services.
This figure is also helpful for figuring out good values for the number of
IPs, HSDirs, etc.
So, as I understand it, here are some reasons for turning this on by
default.
- Both of these stats [https://metrics.torproject.org/hidserv-frac-
reporting.html?graph=hidserv-frac-
reporting&start=2014-06-11&end=2015-09-09 have very low coverage right
now]. The HSDir stat for example is about to go below 1% coverage which
means that it will stop working (we require at least 1% coverage for these
stats).
This is because not many relay operators are running the stats and some
that did have disabled them because they didn't know if they work or if
they are useful.
By turning this on by default, we stop hunting down relay operators to
ask them to enable stats.
- I'm also afraid that this low coverage might be causing our
extrapolations to lie. For example, I could imagine that the bandwidth
graph does not work very well with that low coverage since most clients
that cause lots of traffic connect to relays that are not reporting
statistics. This might be why the spikes are so big on that graph, since
some days we might be lucky and get those busy clients in the stats. I
think it will be very interesting to see how the graph develops when more
of the network reports these stats (and we stop relying so much on our
crazy extrapolation from 1%).
FWIW, I don't think DARPA actually cares about the ''precision'' of these
statistics that much. And it's also unclear if the precision will be much
better since now all 6000 relays will add laplace noise, whereas before
only the 40 relays that reported these stats did (let's just hope that the
noise cancels itself out as it should).
I think this is mainly something we do for ourselves, otherwise these
stats will stop working in some time (when a few more HSDirs join the
network), and we will have to start asking people again to turn it on.
Finally, we have thought about these stats more than we have any other
stat, and we still can't find any nasty attacks that can come from them.
That's why we are OK with enabling them by default.
In any case, I don't really care about this so strongly. I'm personally
fine with disabling these stats again if the community thinks so. But it
would be nice to hear a convincing argument from qwerty1 or whatever on
why (he used to say that these stats can be used to do guard discovery
attacks, which makes no sense!).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15254#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs