<div dir="ltr">Hi again,,<div><br></div><div>> A valid point, thanks for linking the paper. I have the utmost belief </div><div>your intentions are good, but the concentration of exits under a </div><div>non-advertised central control warrants conversation, at least.</div><div><br></div><div>I discussing the best way to handle this is important. However I think it's unfair to expect one small provider to go through the hassle of correlating MyFamily across customers, while big providers like Digitalocean are fine.</div><div><br></div><div>> <span style="color:rgb(33,33,33)">If you grow beyond a /24, it's worth knowing that Tor's current path</span></div><span style="color:rgb(33,33,33)">selection avoids the same /16 for IPv4, and will soon avoid the same</span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">/32 for IPv6:</span><br style="color:rgb(33,33,33)"><a href="https://trac.torproject.org/projects/tor/ticket/24393">https://trac.torproject.org/projects/tor/ticket/24393</a><div><br></div><div>The avoiding /32 will be very positive as IPv6 relays become more wipe spread.</div><div><br><div><span style="color:rgb(33,33,33)">> </span><span style="color:rgb(33,33,33)">If the end goal is turning $ into relays, not all paths are paved with</span><span style="color:rgb(33,33,33)"> </span></div><span style="color:rgb(33,33,33)">equal mind to security and it might be worth considering donation-backed </span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">alternatives.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><font color="#212121">Two things here:</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">1) We are hosting more than just Tor relays. While Tor relay operators are a target demographic, over time we expect to be a free speech friendly hosting provider, and also already offer remote desktops and a vpn service. In the future it's quite possible that we may have a donation option for managed Tor exits. There are a lot of options we could take.</font></div><div><font color="#212121">2) While we can technically access a customer's data if we're motivated enough - we believe splitting control across different operators is important.</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">> </font><span style="color:rgb(33,33,33)">One might worry more what Mega and Gigacorps are doing,</span></div><span style="color:rgb(33,33,33)">secret partner friendly endeavours with Govts against you,</span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">than what some tiny ISP or whoever is doing with a few boxes.</span><div><font color="#212121"><br></font><div>It's quite true hosting providers might collude with law enforcement. Tor isn't designed to fight against a global passive adversary, there isn't enough research on protecting against a such a powerful adversary.</div><div><br></div><div>> <span style="color:rgb(33,33,33)">And was posted here many times about creating additional trust</span></div><span style="color:rgb(33,33,33)">models and layers for relays, audits metrics and choices for users</span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">beyond the CIDR/nn and Family game that might go towards</span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">satisfying some reasonable concerns in that space... but crickets.</span><br style="color:rgb(33,33,33)">><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">> And when you can't trust your CPUs, ISPs, operators, Govts, or</span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">even your own anonymous overlay networks strength against them...</span><br style="color:rgb(33,33,33)"><span style="color:rgb(33,33,33)">it's probably time for strategic rethink.</span></div><div><font color="#212121"><br></font></div><div><font color="#212121">When it gets to the point you are worried all computers have a hardware backdoor, maybe computers and the internet are too dangerous for your thread model and you should consider alternate ways of communication not involving technology.<br></font><div><div><font color="#212121"><br></font></div><div><font color="#212121">Teor: I read your email regarding off-topic emails and I agree. I'm going to create a new thread regarding path selection and relays at the same hosting provider. I don't want to continue a thread regarding Conrad and I's services as that's been discussed enough. Let's discuss path selection among the same hosting provider in general.</font></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 10:09 PM teor <<a href="mailto:teor@riseup.net">teor@riseup.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 28 Aug 2018, at 10:47, Nathaniel Suchy <<a href="mailto:me@lunorian.is" target="_blank">me@lunorian.is</a>> wrote:<br>
> <br>
> Tor will already avoid making circuits where two IP Addresses in the same /24 are involved.<br>
<br>
If you grow beyond a /24, it's worth knowing that Tor's current path<br>
selection avoids the same /16 for IPv4, and will soon avoid the same<br>
/32 for IPv6:<br>
<a href="https://trac.torproject.org/projects/tor/ticket/24393" rel="noreferrer" target="_blank">https://trac.torproject.org/projects/tor/ticket/24393</a><br>
<br>
T<br>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org" target="_blank">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
</blockquote></div>