<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><span>Hi,</span><br><span></span><br><blockquote type="cite"><span>On 20 Jan 2020, at 17:43, Georg Koppen <gk@torproject.org> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>nusenu:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Georg Koppen:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yes, that's what I figured. So, it seems to me not all your proposed</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>keys are equally important (e.g. your require the email one). Which of</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>those (or maybe even which cluster of those) are/is important enough in</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>your opinion to could be considered on topic for a potential tor</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>proposal? (If we would go that route)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>email (if a fully automated verification process is included)</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Okay, that sounds like a promising start.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The only negative point of removing the ContactInfo field</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>altogether is loosing information that people put into it. </span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Well, it does not necessarily mean losing information as the field would</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>not just go away but be replaced by other, more narrowed down ones.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>which seems to imply a configuration change and not all operators will</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>change their configuration</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>That might be true but we'd have some clear process ahead to phase the</span><br></blockquote><blockquote type="cite"><span>old field out and transition to the newer ones, and transparent ways to</span><br></blockquote><blockquote type="cite"><span>enforce the new model after some time.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I feel that's a big plus to an optional spec that kind of exists in</span><br></blockquote><blockquote type="cite"><span>parallel to the status quo and might play somehow a role in determining</span><br></blockquote><blockquote type="cite"><span>whether a relay might get bumped out of the network or not etc.</span><br></blockquote><span></span><div dir="ltr"><br></div><div dir="ltr">If we want to recommend that operators provide an email address</div><div dir="ltr">to stay in the consensus, we should make it easy for operators to</div><div dir="ltr">provide an email. If we have a preferred format, we should</div><div dir="ltr">automatically provide the email in that format.</div><br><span>Here's a rough sketch of a spec that could work:</span><br><span>* add a ContactEmail field to the torrc and descriptors. The field must</span></div><div dir="ltr"> be encoded as UTF-8. (See proposal 285 [0].)</div><div dir="ltr">* do<font color="#000000"> </font><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">some minimal validation on the email field, that makes sure it looks</span></div><div dir="ltr"><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> like an email </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">address. (Or don't, so operators can obfuscate their</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> addresses from spammers.)</span></div></div><div dir="ltr"><span></span><br><span>And then there's a few different transition options, some of which overlap:</span><br><span>0. Do nothing.</span></div><div dir="ltr"><span>1. Combine ContactEmail and ContactInfo in the descriptor's ContactInfo</span></div><div dir="ltr"><span> field, </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">in the format that the ContactInfo spec recommends. </span>If the email is</div><div dir="ltr"> already a substring of ContactInfo:</div><div dir="ltr">1.1. Do nothing.</div><div dir="ltr">1.2. Make sure the ContactInfo email is <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">in the format that the ContactInfo</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> spec recommends.</span></div><div dir="ltr">1.3. Remove the email (and the <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">ContactInfo </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">spec email field name) from</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> the ContactInfo field in the descriptor, and just put it in the</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> ContactEmail field. We could wait a few releases to make this breaking</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> change.</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">2. Warn if the ContactEmail field isn't set on a relay.</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">3. Reject the configuration if the ContactEmail field isn't set on a relay,</span></div><div dir="ltr"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> after a few releases.<br></span><span>4. Rename ContactInfo to OtherContactInfo, but allow </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">ContactInfo as an</span></div><div dir="ltr"><font color="#000000"><span style="caret-color: rgb(0, 0, 0);"> alias for a few releases.</span></font></div><div dir="ltr"><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">5. Deprecate the ContactInfo field in descriptors, and replace it with the</span></font></div><div dir="ltr"><font color="#000000"><span style="caret-color: rgb(0, 0, 0);"> email and other contact info fields, after distributing them in parallel for</span></font></div><div dir="ltr"><font color="#000000"><span style="caret-color: rgb(0, 0, 0);"> a few releases.</span></font></div><div dir="ltr"><br></div><div dir="ltr">Here's my opinion:</div><div dir="ltr"><br></div><div dir="ltr">I'd prefer no validation, combining the fields, and ensuring the email is in</div><div dir="ltr">the ContactInfo spec format. I think we should give a config warning if</div><div dir="ltr">the email is missing.</div><div dir="ltr"><br></div><div dir="ltr">Eventually, we should probably stop duplicating email in the ContactInfo</div><div dir="ltr">and ContactEmail fields. (Although compression helps mitigate the impact</div><div dir="ltr">of this kind of duplication.)</div><div dir="ltr"><br></div><div dir="ltr">I don't think we should rename ContactInfo. It is one way to force</div><div dir="ltr">operators to eventually modify their torrc. But if we want to force a config</div><div dir="ltr">change, let's just require that ContactEmail is set.</div><div dir="ltr"><br></div><div dir="ltr">I don't think renaming or deprecating ContactInfo in the descriptor is</div><div dir="ltr">useful. (Renaming a field breaks a bunch of tools for no good reason.</div><div dir="ltr">And people clearly like having an unstructured or extensible field.)</div><div dir="ltr"><br></div><div dir="ltr">But that's all just my opinion. I've run relays, and made changes to tor,</div><div dir="ltr">but I don't work with this data every day. (Occasionally, I use it as part</div><div dir="ltr">of selecting fallback directory mirrors.)</div><div dir="ltr"><br></div><div dir="ltr">Any proposed Tor changes should be guided by people who deal with</div><div dir="ltr">this data all the time: the network health, bad relays, and metrics</div><div dir="ltr">teams. (And the network team, to help with the design and</div><div dir="ltr">implementation in Tor.)</div><div dir="ltr"><br></div><div dir="ltr">T</div><div dir="ltr"><br>[0]: <a href="https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt">https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt</a><br><br><span style="background-color: rgba(255, 255, 255, 0);">T</span><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">-- </span></div><div><span style="background-color: rgba(255, 255, 255, 0);">teor</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">----------------------------------------------------------------------</span></div><br></div></body></html>