[metrics-bugs] #28529 [Metrics/Analysis]: Confirm that Orbot geoip lookup flaw is resolved

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Nov 20 00:44:02 UTC 2018


#28529: Confirm that Orbot geoip lookup flaw is resolved
------------------------------+------------------------------
 Reporter:  arma              |          Owner:  metrics-team
     Type:  task              |         Status:  new
 Priority:  Medium            |      Milestone:
Component:  Metrics/Analysis  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:                    |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:  Sponsor19
------------------------------+------------------------------

Comment (by teor):

 Replying to [ticket:28529 arma]:
 > Context part one: Georgetown and NRL et al have a paper at IMC 2018 that
 found "that ~40% of the sites accessed over Tor have a torproject.org
 domain name". At the time it was a mystery why.

 onionoo was 40% of the domains accessed by the first stream on each
 circuit, excluding circuits where the first stream used an IP address.

 Page 6 of https://www.ohmygodel.com/publications/tor-usage-imc18.pdf

 > Context part two: pastly or teor or somebody in Mexico City realized
 that Orbot had a design mistake where it did an onionoo lookup (over Tor)
 of the exit relay for its circuit, rather than shipping its own geoip db.

 Matt Finkel discovered the relevant code in Orbot:
 https://gitweb.torproject.org/orbot.git/tree/orbotservice/src/main/java/org/torproject/android/service/TorEventHandler.java#n226

 This code performs an Onionoo lookup for every relay in every circuit
 built by Tor. Each lookup creates one stream, and possibly one circuit
 (if the previous Onionoo circuit has timed out).

 Tor always tries to keep 6 preemptive circuits open, leading to 6*3 = 18
 lookups when Orbot starts.
 Every new circuit triggers another 3 lookups, one for each relay in the
 circuit. (There is no caching, as far as I can see.)

 > Context part two-b: They also discovered that around the time of that
 feature roll-out in Orbot, our onionperf graphs start to look uglier
 especially in terms of performance variance.

 The feature was added in September 2016:
 https://gitweb.torproject.org/orbot.git/tree/orbotservice/src/main/java/org/torproject/android/service/TorEventHandler.java#n25

 The initial version of the code was correlated with a significant rise
 in circuit download times across the whole Tor network:
 https://metrics.torproject.org/torperf.html?start=2015-01-01&end=2018-09-30&source=all&server=public&filesize=50kb

 (I'm not sure why download times became much more consistent in
 mid-2017. Perhaps the Orbot code changed, or we improved tor network
 performance another way.)

 > Context part three: I think Nathan thinks he fixed the issue in the
 "Orbot 16.0.3-BETA-2" release on Oct 12. I remember we tracked down what
 we thought was the fix to a commit that had an unrelated commit message.
 >
 > Today I saw another Orbot release mail, for "Orbot
 16.0.5-RC-1-tor-0.3.4.9".
 >
 > So: is there a graph or stats somewhere about adoption of Orbot
 versions, to get a handle on how many Orbot users have this fixed version
 vs how many don't?

 Good question.

 > And, can we see any changes on the onionperf results as the fix got
 rolled out?

 I see no changes yet, but they are beta and RC releases.

 https://metrics.torproject.org/torperf.html?start=2018-09-01&end=2018-11-20&source=all&server=public&filesize=50kb

 > And, once we think the fix has been rolled out to most Orbot users,
 could we do another privcount run on some exits to see if the anomaly went
 away?

 I no longer control any exits, but the rest of the deployment might still
 exist.
 I still have the configurations for all the measurements we did for the
 paper.

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


More information about the metrics-bugs mailing list