Roger Dingledine:
but it doesn't address the key question: How do you specifically define "known" and how do you verify entities before you move them to the "known" pool?
Well, the first answer is that these are two separate mechanisms, which we can consider almost independently:
- One is dividing the network into known and unknown relays, where we
reserve some minimum fraction of attention for the known relays. Here the next steps are to figure out how to do load balancing properly with this new parameter (mainly a math problem), and to sort out the logistics for how to label the known relays so directory authorities can assign weights properly (mainly coding / operator ux).
- Two is the process we use for deciding if a relay counts as known. My
suggested first version here is that we put together a small team of Tor core contributors to pool their knowledge about which relay operators we've met in person or otherwise have a known social relationship with.
How does the verification process look like to become "known"? Tor core people handing out printed tokens to people that are able to attend one of your preferred conferences or what do you have in mind specifically?
Here the next step is to figure out the workflow for annotating relays. I had originally imagined some sort of web-based UI where it leads me through constructing and maintaining a list of fingerprints that I have annotated as 'known' and a list annotated as 'unknown', and it shows me how my lists have been doing over time, and presents me with new not-yet-annotated relays.
Lets annotate on a family (and not relay) level.
If we had verified contacts, we could avoid MyFamily and use the verified contact only.
As a starting point you can use the family listings on this page: https://nusenu.github.io/OrNetStats/
One of the central functions in those scripts would be to sort the annotated relays by network impact
OrNetRadar provides family lists sorted by CW fraction, guard and exit probability. These lists also contain the date when the family joined.
You can even directly spot the likely malicious exits that are currently recovering from the last attempt to get rid of them especially since you know the specific date when dir auths last attempt to get rid of them was.
regards, nusenu