[metrics-bugs] #32473 [Metrics/Exit Scanner]: Evaluate the results from the exitmap based scanner compared to the current exit lists system
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Nov 27 18:11:17 UTC 2019
#32473: Evaluate the results from the exitmap based scanner compared to the current
exit lists system
----------------------------------+------------------------------
Reporter: irl | Owner: metrics-team
Type: task | Status: new
Priority: Medium | Milestone:
Component: Metrics/Exit Scanner | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
----------------------------------+------------------------------
Comment (by irl):
Replying to [comment:3 karsten]:
> I compared those exit lists from the new exit scanner (only 2019-11-26
or later) to the ones published by the old exit scanner from the same time
frame. I attached my output file that organizes scan results by
fingerprint. Some observations:
>
> - The new scanner omits a handful relays that the old scanner scanned.
I assume this is related to exit policies? The absolute number of these
cases is rather low, but please take a look, too (at the beginning of the
output file).
These are all exit policy related. The current implementation requires
port 443 to be allowed. A future version, with the help of TSA and
iptables, could work around this limitation. It looks like the current
scanner starts a listener on port 80 but I don't know Haskell enough to
understand what it is doing.
> - The vast majority of scans (over 1,000) result in the same exit
address. There are just 6 relays with 2 or more exit addresses by either
old or new scanner. It's hard to say which scanner is right here. Maybe
it's just relays on dynamic IPs or with multiple IP addresses. Please take
a look at these (grep for "exit addresses total").
These look like dynamic IPs, I can't see anything that would suggest
otherwise.
> - Looks like the new scanner doesn't properly clear old scan results.
I'm only looking at results from 2019-11-26 and later, and yet there are
scan results from 2019-11-19 and 2019-11-20. This seems like a (small)
bug.
Yes, I'd disabled that to test merging with an older file, I'll uncomment
that code again. (:
> That's all. Overall, I think that these results are as close to the
current scanner as they can get. If we can resolve that one bug and get
your confirmation that the other two things are normal, I think we're good
to go.
Awesome!
I will hopefully wrap up #32264 tonight and then #32265 tomorrow, and then
deploy to AWS over the weekend to evaluate again before asking TPA for a
machine.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32473#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the metrics-bugs
mailing list