[tor-bugs] #10218 [Tor]: Provide "users-per-transport-per-country" statistics for obfsbridges

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Feb 15 17:18:05 UTC 2016


#10218: Provide "users-per-transport-per-country" statistics for obfsbridges
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:
     Type:  enhancement                          |  joelanders
 Priority:  Medium                               |         Status:
Component:  Tor                                  |  assigned
 Severity:  Normal                               |      Milestone:  Tor:
 Keywords:  tor-bridge tor-pt bridgedb-dist      |  0.2.8.x-final
  028-triage                                     |        Version:
Parent ID:                                       |     Resolution:
  Sponsor:                                       |  Actual Points:
                                                 |         Points:  medium
-------------------------------------------------+-------------------------

Comment (by karsten):

 Here's something else we could do to get a first estimate of users per
 transport and country that doesn't require adding new statistics.

 It turns out that most large bridges (4 out of 5 on February 1, 2016) only
 see noteworthy usage via a single transport or have requests via one
 transport dominating the others in numbers (74% on the 5th large bridge on
 February 1, 2016).  Example:

 {{{
 A72D5DB45D9DE4B244D3F6C4AD22A66F40BF5B87,bridge,responses,,<OR>,,2016-02-01
 00:00:00,2016-02-02 00:00:00,4.3
 A72D5DB45D9DE4B244D3F6C4AD22A66F40BF5B87,bridge,responses,,obfs3,,2016-02-01
 00:00:00,2016-02-02 00:00:00,26892.1
 73D8FF840444F84EC50DD755FBAD44CF1F0DE28B,bridge,responses,,<OR>,,2016-02-01
 00:00:00,2016-02-02 00:00:00,4.3
 73D8FF840444F84EC50DD755FBAD44CF1F0DE28B,bridge,responses,,obfs3,,2016-02-01
 00:00:00,2016-02-02 00:00:00,26787.2
 88F745840F47CE0C6A4FE61D827950B06F9E4534,bridge,responses,,meek,,2016-02-01
 00:00:00,2016-02-02 00:00:00,22049.6
 3E0908F131AC417C48DDD835D78FB6887F4CD126,bridge,responses,,<OR>,,2016-02-01
 00:00:00,2016-02-01 17:52:31,8.3
 3E0908F131AC417C48DDD835D78FB6887F4CD126,bridge,responses,,obfs3,,2016-02-01
 00:00:00,2016-02-01 17:52:31,15245.3
 3E0908F131AC417C48DDD835D78FB6887F4CD126,bridge,responses,,obfs4,,2016-02-01
 00:00:00,2016-02-01 17:52:31,4764.3
 3E0908F131AC417C48DDD835D78FB6887F4CD126,bridge,responses,,scramblesuit,,2016-02-01
 00:00:00,2016-02-01 17:52:31,476.2
 AA033EEB61601B2B7312D89B62AAA23DC3ED8A34,bridge,responses,,<OR>,,2016-02-01
 00:00:00,2016-02-02 00:00:00,10.6
 AA033EEB61601B2B7312D89B62AAA23DC3ED8A34,bridge,responses,,meek,,2016-02-01
 00:00:00,2016-02-02 00:00:00,19024.7
 }}}

 The four bridges with a single transport are easy.  The distribution of
 requests by country exactly matches the distribution by country and
 transport.  Done.

 The fifth bridge with multiple transports is trickier.  We could assume
 that the distribution by country is the same for all transports, that is,
 if `CC` (in `[0..1]`) requests came from a given country and `PT` (also in
 `[0..1]`) requests came in via a given transport, `x * y` requests can be
 attributed to that country and transport.  But that assumption may be
 wrong.  What we could also do as first approximation is find a lower and
 upper bound of users by country and transport.  The lower bound would
 probably be defined as something like `max(0, PT + CC - 1)` (not just `0`
 to account for cases where `CC > 1 - PT`) and the upper bound as `min(PT,
 CC)`, even though I could be convinced that other formulas are even more
 correct.

 My guess is that this approximation would provide us with some insights
 about actual usage and about requirements for better statistics.  The best
 part is that all required data is already available, we just need to look
 at it.

 The bad news is that I don't have the time before the dev meeting to run
 this analysis, and I can't even say whether the weeks after the dev
 meeting will be any better.  That's why I
 [https://people.torproject.org/~karsten/volatile/merged-2016-02-01.csv.xz
 uploaded the data] for somebody else to do the analysis and publish
 results here.  Any takers?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10218#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list