- network-health - lists.torproject.org

Official country list ban access to TOR
by Ulyses uly 26 Feb '22

26 Feb '22

Hi, I'm a student of cyber intelligence master degree. Now, I am studying which countries officially censor the access to the TOR network (in their laws, penal code, ...). There is a lot of misinformation so, Do you have any official country list about it? Thanks so much :)

1 0

Tor Bridge/Relay Location
by Matthew Raposo 30 Dec '21

30 Dec '21

Hello, I was wondering if Relays and Bridges are specific to a country. If, for example, I am a bridge in the United States can I act as a Bridge for Tor users in other countries? If so, is there a range for how far a Bridge or Relay can be acting for other users? Thank you for your time. Sincerely, Jeff

2 1

(no subject)
by Rajat Sinha 05 Dec '21

05 Dec '21

Good

1 0

More details about bad-relay proposal
by Garún 19 Nov '21

19 Nov '21

Hello everyone, yesterday during the State of the Onion stream, Georg mentioned a proposal that considers the implementation of a relay trust factor in order to prevent malicious operators from getting the bandwidth they want. I wanted to ask if there are any sources I can read into for more details about this? Or if more information could be provided on the proposal? It sounds a bit like this is going into the direction of nusenu's web of trust [1]. Garún [1] https://nusenu.github.io/tor-relay-operator-ids-trust-information/

2 1

Question about authority nodes
by Daniel Mider 11 Oct '21

11 Oct '21

Dear All, First of all, I would like to say that TOR is great and you are doing a very important job globally. I would like to ask where I can find information on TOR directory nodes. Are there 9 of them? Apparently, each of them is controlled by a different organization. What are these organizations called? Regards Daniel Mider

2 1

Atlas identifying asn incorrectly.
by joe＠farnell.org.uk 27 Sep '21

27 Sep '21

Hi, the tor atlas is identifying relays hosted on AS211144 as being hosted on AS211365. Please can this be corrected?

2 1

Queries about user statistic on Tor Metrics
by Nowshin, Nafisa 22 Sep '21

22 Sep '21

Hello, I am a graduate student at Oregon State University doing research on digital privacy and security. My advisor is Dr. Glencora Borradaile. We are trying to use tor metrics data in order to understand the reason why people are connecting to tor and if it is because of some external motivation (the topic of our research) or because they are regular users. Looking at the user statistics available in tor metrics website, we had a few questions we wanted to clarify. 1. How frequently tor browsers send out update pings? Is there a fixed frequency or do they vary over time? 2. Are update pings sent every time a user opens their browser or only when new updates are pushed to the tor browser? Thank you for your time. Regards Nafisa Nowshin Graduate Assistant School of EECS, Oregon State University

3 2

merging with metrics-team@ mailing list
by Gaba 10 Sep '21

10 Sep '21

Hi people! We just moved everyone that was subscribed to metrics-team@ mailing list to this network-health@ one. Welcome everybody! This new team is maintaining all the metrics software that we run and is responsible of the state of the network. You can read more about it at http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/n… cheers, gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

'margot like' feature request
by Roger Dingledine 02 Apr '21

02 Apr '21

Hi David! A feature request based on (what I understand of) your hackweek project: I often find myself in the position where I have a set of fingerprints, and I want to know if I've "got them all". So something that inputs a set of fingerprints, and outputs an ordered list of candidate "similar" relays, would be a great tool. What exactly we mean by similar, of course, will be a thing we need to iterate on. If we had a huge dataset -- with ground truth -- we could machine learning it and see how the black box gods answer. But while that thought leads to "good idea, let's collect that data set", we need something else in the mean time. Here's a start: * Component-wise similarity is computed differently for each component (version/contactinfo/nickname is a string comparison, IP address is looking for other relays on the same /x network, uptime is computing the real uptime based on the descriptor timestamp minus the descriptor uptime, etc), * But the *strength* of a match is based on how few other relays also matched. That is, we find a component match less compelling the more relays there are that match. For example, maybe the /16 address similarity is a weak match, because there are many relays on that same /16, but the /24 address similarity is a strong match because there's only one other relay closeby. * We can start out with simple comparisons, but eventually we'll want fuzzy comparisons, where e.g. we look at the Levenshtein distance for nickname ("Anonymous1, Anonymous2, Anonymous3"), or check if the two uptimes are within a threshold percentage of each other, etc. * And then the overall similarity is a function of the strength of each component-wise similarity. To start, we could just have it be a linear combination of each, with equal weighting, which means the more components have a strong match, the greater the overall similarity score. There's a lot of opportunity for improvement here, like, weighting certain components more, or non-linear weights where e.g. it's especially interesting when both bandwidthrate and bandwidthburst are strong matches. * So that's how we decide if *two* relays are similar to each other. But if I give you *ten* relays, we need a way to figure out what those relays have in common, to decide whether an eleventh relay is related to the group as a whole. The easy version here is to just do pairwise comparisons between each input relay and each consensus relay, and then sum the overall similarities into a score for each candidate. This approach should *implicitly* take into account similarity between input relays, on the theory that if A is similar to C and B is similar to C, then A is probably similar to B too. For extra credit, we could do some smarter combination than just summing them, but I don't have anything in mind yet. For comparison, check out phw's trnnr tool from the SybilHunter paper: https://github.com/NullHypothesis/trnnr/blob/master/trnnr.py which does a simplified version of the above (it only takes in one relay, it doesn't do the "strength of match is inversely proportional to how much of the population matches" part, and also it has a slick way of comparing all the components at once by just turning them all into a big unified string, which is simple but also has bizarre effects: every character in the IP address string is equally important, and the importance of each component is a function of how many characters it takes to represent it, which is...weird. :) But in general, this script is a great start to look at first. --Roger

1 0

Relays that can't extend
by Roger Dingledine 31 Mar '21

31 Mar '21

Hi folks, I've been probing which relays can't extend to my relay: https://metrics.torproject.org/rs.html#details/7B35DB92BA72BA0BBFD51B35B11A… I'm simply making two-hop paths from my client through every relay to my destination relay. Here's a snapshot of some relays that fail most/all of the extend attempts. The first data set is Feb 27 through Mar 1, and I've attached it as feb27-mar1.txt. The second data set is Mar 30, and it's attached as mar30.txt. The way to read each line of the ratio is: number of failed extend attempts / (number of failed + number of succeeded). (There are some edge cases where I failed to reach the relay as the first hop, for example because it has gone down, or it's in the new consensus but my Tor client doesn't have the descriptor for it yet. I've omitted those edge cases from the ratio calculation, since they're not failures and they're not successes so they just muddy the analysis.) Then I combined them: cat feb27-mar1.txt mar30.txt |sort > combined.txt to make it easy to see which relays had problems in both sets. I've started mailing some of the relay operators to ask them to investigate. (Many of them alas have no workable contactinfo.) The most likely explanation is that they're out of file descriptors (in which case their Tor logs should be complaining constantly). A backup explanation might be that their relay is censored from reaching my relay, perhaps by destination port or address. Eventually we'll want to use these results to compare against the self-reported "overload" metrics from Proposal 328 ("Make Relays Report When They Are Overloaded". I'm not sure what the step after that is, but maybe it will be reducing the consensus weights for relays that aren't performing well. --Roger

2 3