<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 22. Feb. 2020 um 17:11 Uhr schrieb nusenu <<a href="mailto:nusenu-lists@riseup.net">nusenu-lists@riseup.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Michael Gerstacker:<br>
>>> But as long as my family is still a small<br>
>> It is rather hard, time consuming and error prone<br>
>> to asses group sizes without proper MyFamily declarations.<br>
>><br>
> I am the operator of my relays so if i for whatever reason decide to not<br>
> publish that i run a bigger family then this should be my own decision.<br>
<br>
There are two notions to this, depending on what you mean by 'publish'.<br>
<br>
'publish' in the sense of linkability relays <-> operator identity:<br>
Correct there is no need for that.<br>
<br>
'publish' in the sense of declaring a proper MyFamily set:<br>
<br>
from the tor manual page:<br>
"If you run more than one relay, the MyFamily option on each relay **must** list all other relays"<br></blockquote><div><br></div><div>I will list them or shut them down. Just not right now.</div><div><br></div><div>I thought about why i do not want to list them right now and this reason might sound stupid to others but for me including a new relay into MyFamily is some sort of "celebration".<br></div><div>When i include a new relay i commit myself to care for it for the next time period (no matter how long that means).<br></div><div>For me that means checking nyx and the logfile everyday and taking a quick look into nmon.</div><div><br></div><div>So as an operator who paies the bills for my new children i expect the torproject and all affected people to wait till i did my "celebration" or take the necessary steps and reject them so that i understand this as a message that the celebration took too long and that these relays are not wanted anymore.</div><div><br></div><div>I think i do not want to automate this because it would destroy my celebration.<br></div><div>I already automated upgrades because i see a purpose in this but from my point of view i can not see any porpose to automate MyFamily.</div><div><br></div><div>I also thought about why i include them in MyFamily at all and i think the reason is because i want that others have the possibility to exclude my relays if they see a need to do so.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> If the torproject needs these information urgently they need to force it<br>
<br>
The Torproject Inc does not run the Tor network, nor the majority of Tor directory authorities,<br>
but yes, some Torproject employees play a key role on what gets actually enforced on the network and what not<br>
and The Torproject produces the software that dir auths run so they have at least partial/indirect control over the imposed rules<br>
and the network.<br>
As far as I know there is no formal or informal written agreement between Tor directory authorities as to how they run the network. <br>
Past attempts by a Torproject employee an me, to establish something like that unfortunately failed [1].<br></blockquote><div><br></div><div>I think i remember something where nick explained that he (or any other torproject member listed on the torprojects peoples page) can not directly tell the authorities operators what they should do.</div><div>This made me think about for the first time what the torproject actually is.<br><br></div><div>And i think that the way it is right now is actually a good thing. Maybe it even must be like that to ensure free speech as good as possible and to not make some people a big target.<br></div><div>Bu its funny to hear from one of the main designers of Tor that he can actually not really decide what happens.</div><div><br></div><div>I think there is the difference between a normal company and Tor and thats the reason why i am okay paying bills without getting something countable back (beside the fact that i learned a lot in many ways since i started my first relay).<br></div><div><br></div><div>I think it is impressive how good this project works and i think you would put that at risk if you try to force standards too easily and telling directory authorities operators how to run them is one of these examples.</div><div><br></div><div>Of course i only see what i can see and i see that you are more involved than i am but i think as long as its not broken dont try to fix it.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> Not proposing relays of honest operators for removal should be in the<br>
> interest of all to help protect tor users<br>
<br>
It is hard to tell honest operators from others if the relay has no ContactInfo <br>
or does not reply to emails. Even if they reply it can be non-trivial. So if there were actual technical rules<br>
they should apply to all relays equally and not just to dishonest operators<br>
because how do you define and measure "honest" operator?<br>
Should an operator who confirms to bad-relays@ that he setup modified relays to collect onion addresses<br>
be allowed on the network because he is at least honest about it? <br></blockquote><div><br></div><div>(Just for the record i had contact info on all my relays and check that email address weekly. Since my first exit even daily.)<br></div><div>Yes of course this is a problem and the only "solution" is to raise the bar for all.<br></div><div>But this is not what MyFamily is doing. It is raising the bar for the honest ones but not for the dishonest ones.</div><div><br></div><div>If this problem need to get fixed i propose using a contact email address as a replacement of MyFamily and sending a validation email.<br></div><div>Maybe even send another validation email after some randomized timeframe from time to time to validate that the operator is still caring and reachable.<br></div><div>This way you at least raise the bar for all and most honest operators will just use one email address for it so automatically using this one as "the family" is easy.<br></div><div>If a malicious entity wants to put for example 20 relays on the network with different contact email addresses this is still manageable but 200 of them is a whole other thing.</div><div><br></div><div>Sending validation emails is generally stupid but if this would solve a problem which needs a fix then why not?</div><div>People are used to it because whatever they do on the internet they get a validation email and the torproject already uses this for its mailing lists.</div><div><br></div><div>The idea with somehow using the comtact info was raised here already but never really discussed:<br><a href="https://trac.torproject.org/projects/tor/ticket/6676">https://trac.torproject.org/projects/tor/ticket/6676</a></div><div><br></div><div>About the question if someone should be allowed to for example collect onion addresses with a modified tor client/relay:<br></div><div>Actually in the first moment i would say yes.</div><div>Where is the difference between a crazy user writing down every onion he can find an an automatic system doing this?</div><div><br></div><div>If you are talking about HSdirs collecting the hidden services they got i would say "better not" because this is not what they were made for and i can not see a benefit for the network.</div><div><br></div><div>But this should be technically solved and not by blocking them and as far as i know v3 onion addresses are solving that problem so an hidden service operator can now choose if they want to take that risk or they could use client authentication right away.</div><div><br></div><div>Another reason to allow it would be because if you dont allow it but it is still possible and someone do this and you try to solve that by blocking them that means you are constantly failing in what you do because if they want to do it then they will just come back.</div><div><br></div><div>But if you say "Yes it is allowed! (... if you are able to do it) then you have a competition and an overall improvement or at least a bigger viewpoint about what to fix, what to allow and where to aggree.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> but an opt-in solution for<br>
> MyFamily which gets forced by random people on a public [tor-]bad-relays<br>
> mailinglist <br>
<br>
bad-relays@ is not public in the sense that everyone can read it, but everyone can send to it,<br>
which is its main purpose.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
<br>
[1] <a href="https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548" rel="noreferrer" target="_blank">https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548</a><br>
<br>
<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></div>