Re: [tor-relays] Would you place your secrets or in worst case make your life

[zwiebeln <zwiebeln@xxxxxxxxx>]

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 <zwiebeln@xxxxxxxxx> 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
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays