Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21315: publish some realtime stats from the broker?
-------------------------------------+--------------------------------
 Reporter:  arma                     |          Owner:  (none)
     Type:  enhancement              |         Status:  needs_revision
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:  #29461                   |         Points:
 Reviewer:  irl                      |        Sponsor:  Sponsor19
-------------------------------------+--------------------------------
Changes (by irl):

 * status:  needs_information => needs_revision


Comment:

 Number of currently available snowflake proxies is not sensitive. We do
 not make any efforts to hide the numbers of relays or bridges, and so this
 can be an exact count. The question here is not the count resolution but
 the time resolution. (Sorry to answer your question with a question.)

 If I'm an attacker, can I learn anything about a client if I can observe
 the client's traffic and the exact count of snowflakes. For example, what
 do I learn if a snowflake that a client is using disappears? I'm not sure
 what the snowflake protocol does in this case.

 I'm not sure what you mean with the GeoIP stats. If these are stats
 regarding the locations of proxies, again exact counts would be fine and
 would be in line with what we do for relays and bridges at the moment. If
 this is for clients, we should aim to provide differential privacy. I fear
 that at the moment, we are not seeing enough users that we can safely
 report GeoIP stats (usefully) for clients at all. With relays and bridges,
 we round the counts up to the nearest multiple of 8.

 Round trip time of snowflake rendezvous sounds like a really useful metric
 for engineering work, but a dangerous one for safety. This would be a good
 candidate for PrivCount but without such a technique I wouldn't do this
 one. We currently measure performance of relays using active measurement,
 such that we are only analyzing our own traffic. We have extended that
 tool, OnionPerf, to also work for pluggable transports but it will do the
 end-to-end performance not just client->snowflake.

 Can you lay out in detail exactly what metrics you'd want, what resolution
 data you want (both in counts and in time) and what you might consider an
 attacker could learn, assuming they are in a position to monitor, or are
 running, a point in the network?

 Section 2.1.2 of dir-spec contains some examples of descriptions of
 metrics.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21315#comment:14>
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