[tor-dev] tor relay process health data for operators (controlport)

Iain Learmonth irl at torproject.org
Tue Feb 5 15:46:02 UTC 2019


Hi All,

On 04/02/2019 06:35, teor wrote:
> If we add enough noise to protect most users, then we will have privacy by design.

I would argue that noise does not help here, as we would have to add
enough noise to protect against a guard discovery attack, which is too
much noise for the stats to be useful.

I only learned that these stats have such high resolution last week and
I'm very concerned about this.

Regarding limiting retention time, if I'm trying to pull off a guard
discovery attack then I'm probably going to be interested in only the
timeframe that relates to my attack. Retention periods aren't going to
help here and may in fact make it worse if LE suspects that the data
would disappear after a given time period and so issues an emergency
order that might be even more restrictive or carry heavier sanctions for
non-compliance.

Are the statistics in the extra-info descriptor really not useful for
the purpose of graphing to monitor health? If they are not then we
should come up with ways of addressing this but if they are then we
should not be retaining any more data than that which is already public.

If we think that the 6-hour statistics are safe to collect (which we
previously decided they were not when we changed the granularity of the
bandwidth stats) then we could add them to extra-info descriptors.

I am worried that exposing/retaining statistics without a proper review
of the attacks they enable, even with the best guidelines in the world,
is dangerous. If we have retention guidelines we also have no way to
enforce those and this could introduce a systemic weakness in the network.

I have filed #29344 to consider these things.

Thanks,
Iain.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190205/e1f5674e/attachment.sig>


More information about the tor-dev mailing list