There is only a small path between moderation and censorship – to get my message released after four days is close to…
Your answer Theo is rather technical and doesn't apply really on the underlying question: „Would you place your secrets or in worst case make your life depended on a network that is 21 percent controlled by a single person that you don't know?“ Your assumption: „But ultimately, if we doubled tor's exit bandwidth, this issue would go away. That's the best solution to this problem.“ - is wrong. The Exit only https://metrics.torproject.org/bandwidth-flags.html?start=2017-11-19&end=2020-02-17 has more than doubled in the last two years – while the exit probability of this single person decupled. „Perhaps you could run more relays?“ - I am with the project now for more than three years an do run a exit probability somewhere close to 2 percent, that i don't like to increase, because i think it is a more than healthy fraction for a singe person – so why do you insinuate, my question is not in a „good faith“? I hope more people do come on board of this discussion now! Paul On 17.02.20 02:53, teor wrote: > Hi, > > A quick reminder to everyone on this list: this list is moderated. > Please keep your replies helpful and on topic. > >> On 13 Feb 2020, at 22:05, zwiebeln <[email protected]> wrote: >> >> depended on a network that is 21 percent controlled by a single person >> that you don't know? >> >> https://nusenu.github.io/OrNetStats/allexitfamilies >> >> I think we should start an open debate on that fact, best ending up with >> giving some recommendations. I am sure that question is relevant to >> torproject.org as well. > > We've had similar questions a few times on this list. > > The most common answer is: > > "Let's encourage people to run more relays." > > Perhaps you could run more relays? > Or ask for help improving your consensus weight? > > The operator of those relays is on this list, asks questions, and > responds to emails. They've been helpful in the past. > > So please ask questions in a way that assumes good faith: > https://en.wikipedia.org/wiki/Good_faith > You'll be more likely to get a helpful answer. > > It's also important to keep network risks in perspective: > * 99% of relays run Linux, and a significant number of those are Debian > (or Ubuntu, or other derivatives) > https://metrics.torproject.org/platforms.html > * there is 1 bridge authority (100%), 6 bandwidth authorities (17%), > and 9 directory authorities (11%) > * the consensus algorithm tries to limit the risks of one directory > authority influencing large parts of the tor network, and manual > bridge distribution limits the impact of the bridge authority > * the largest ASes have: > * 23% of guards and 22% of middles (Hetzner) > * 16% of guards and 12% of middles (OVH) > * 10% if guards (Online) > * 20% of exits (J P McQ) > https://metrics.torproject.org/rs.html#aggregate/as > > So it's not really helpful to single out a particular operator or > network. > > As far as I recall, the most widespread security issue that's happened > to the network was the Debian OpenSSL bug: > https://www.debian.org/security/key-rollover/ > > There are all kinds of risks that happen when a large part of the > network has a similar setup: > * relay operator compromise > * AS operator compromise > * platform compromise > * observation of traffic via common network infrastructure > * network availability > * poor performance > * poor bandwidth weights > > Tor relay consensus weights are determined by the bandwidth > authorities, so we might also be seeing: > * a bug in the bandwidth authority software (sbws or Torflow), or > * a majority of bandwidth authorities configured in a way that > concentrates bandwidth in particular areas. > > I've opened a ticket in sbws to track this issue: > https://trac.torproject.org/projects/tor/ticket/33350 > (Torflow is unmaintained, and we're planning to completely replace it > with sbws in 2020 or 2021.) > > I'll also ask our new Network Health team to consider the risk of > large operators and large ASes. Hopefully they can recommend some > changes to the bandwidth authorities (or sbws maintainers). > > But ultimately, if we doubled tor's exit bandwidth, this issue would > go away. That's the best solution to this problem. > > Again, please keep your replies helpful and on topic. > > T > > > _______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
