<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><blockquote type="cite"><span>Date: Fri, 10 Apr 2015 15:47:23 +0300</span><br><span>From: George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>></span><br><span></span><br><span>David Goulet <<a href="mailto:dgoulet@ev0ke.net">dgoulet@ev0ke.net</a>> writes:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>On 09 Apr (21:58:49), George Kadianakis wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hello,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I inline a proposal for Direct Onion Services. It's heavily based on</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the "encrypted services" proposal of Roger, but I refined it, made it</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>more proposaley and enabled a few more optimizations. You can find the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>original piece here: </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> <a href="https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted-services.txt">https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted-services.txt</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Feedback would be greatly appreciated.</span></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">[snip]</blockquote></blockquote><blockquote type="cite"><span></span></blockquote><br><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>- We really really need a better name for this feature. I decided to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> go with "Direct Onion Services" which is the one that the NRL people</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> suggested here:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> <a href="https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html">https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> I'm not super happy with it, but I can't think of better ones myself.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Here are some candidates: </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 1 Way Anonymous Hidden Services</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Fast Onion Service</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Short-circuited Onion Services</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Fast-but-not-hidden Services</span><div style="display: none;"><br></div></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it</span><br></blockquote><blockquote type="cite"><span>because it describes pretty much what it is and the acronym is FOSS. :)</span><div style="display: none;"><br></div></blockquote><div style="display: none;"></div><blockquote type="cite"><div style="display: none;"><span></span><br></div></blockquote><span></span><br><span>It's not clear to me why acronym collisions are a plus :)</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>- We also need a better torrc option. If the name of this feature does</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> not portray its dangers, then the torrc option should be a bit</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> terrifying. That's why I went 'DangerousDirectOnionService' which I</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> actually don't like at all. BTW, it's unclear whether this mailing</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> list is the best place to brainstorm for names.</span><div style="display: none;"><br></div></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This one depends on the name quite heavily but I don't think we should</span><br></blockquote><blockquote type="cite"><span>have a scary name. Scary name seems to me they will simply bring more</span><br></blockquote><blockquote type="cite"><span>questions without context of the actual feature. What is "Dangerous"</span><br></blockquote><blockquote type="cite"><span>about this, why is it in Tor at all?... This could simply be resolved by</span><br></blockquote><blockquote type="cite"><span>clear and thorough documentation of the risks/benefits of the options.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>For instance, we could *not* put it in the default torrc file and thus</span><br></blockquote><blockquote type="cite"><span>will only be in the man page with *good* documentation. Like you said</span><br></blockquote><blockquote type="cite"><span>also in the proposal, a big warning is very important at boot.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If it's off by default and not present in the torrc file, there are no</span><br></blockquote><blockquote type="cite"><span>reasons why someone would enable this just because it's says</span><br></blockquote><blockquote type="cite"><span>"DirectOnionServiceEnable". (Ok I might be an optimist but still, we are</span><br></blockquote><blockquote type="cite"><span>not that responsible for reckless HS operator ;)</span><div style="display: none;"><br></div></blockquote><span></span><br><span>Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK</span><br><span>with changing the proposal to use 'DirectOnionServiceEnable' but I would</span><br><span>prefer if it's a bit more alarming.</span><blockquote type="cite"><span>[snip]</span></blockquote></blockquote><div><br></div>I've been hesitant to weigh in on the naming conversation for hidden services. But I am concerned about the issues raised in the previous few emails on the topic.<div><br></div><div>Matt @ Speak Freely has a strong point about acronym collisions - they only serve to confuse users and dilute the search space. And usability becomes a security issue as soon as names are confusing to users.</div><div><br></div><div>Others have also made important points about how we name things in general.</div><div><br></div><div>So I'd like to propose some general naming principles, mostly distilled from recent conversations about names:</div><div>1. Avoid acronyms that collide with popular acronyms, particularly those in the security / software / technology spaces.</div><div>2. Names should be kept consistent across the entire Tor code base and ecosystem.</div><div>3. When selecting option, feature, and concept names:</div><div>A) Names should describe the most important user-visible impact of an option, feature, or concept.</div><div>B) <span style="background-color: rgba(255, 255, 255, 0);"> If the feature has a serious impact on anonymity (or other typical user assumptions), the name should indicate that.</span></div><div>C) Names should avoid specific implementation details, as these may change.</div><div>D) Names should avoid giving relative opinions on performance, security, or privacy impacts, as these are often dependent on context.</div><div>E) Project names are an exception to principle 3, and should have abstract names, or descriptive acronyms.</div><div><br></div><div>My evaluation of the suggestions around hidden services / onion services based on these principles is:</div><div><br></div><div><blockquote type="cite">Onion Service</blockquote><br></div><div>Collides with OS, or Operating System, violating principle 1: no collisions.</div><div><br></div><div>If we decide to disregard this acronym collision, and accept the usability impact, every option and the entire manual page should be changed in the same release, to satisfy principle 2. This would involve a transition period in which both HS and OS options would work. (We should also consider the usability of options with OS in the name before making the switch.)</div><div><br></div><div></div><blockquote type="cite"><div>Direct Onion Service</div><div>Dangerous Direct Onion Service</div></blockquote><div><br></div>As it's already been noted, these collide with DOS and DDOS (1), and don't describe which end is direct (3A & 3B).<div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div></div><blockquote type="cite"><div><span style="background-color: rgba(255, 255, 255, 0);"> Fast Onion Service</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> Short-circuited Onion Services</span></div></blockquote><div><br></div><div>I'm concerned about the collisions with OS implied by these acronyms (1).</div><div>Also, the first provides a performance goal (3D), and the second, an implementation detail (3C). Neither describes the most important user-visible behaviour - lack of server anonymity (3B).</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><blockquote type="cite"><span style="background-color: rgba(255, 255, 255, 0);">Fast-but-not-hidden Services</span></blockquote></div><br></div><div>This seems to combine a performance goal (3D), with a description of the impact of the service. Aren't we better to address the speed / anonymity trade off in the manual and other documentation?</div><div><br></div><div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"> 1 Way Anonymous Hidden Services</span></font></blockquote></div><div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">This is descriptive (3A & 3B), but which end is anonymous?</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Why not state that it's the client:</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Client Anonymous Hidden Services</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Or, even better, state that the server is non-anonymous:</span></div></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">Exposed Server Hidden Services</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Public Server Hidden Services</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Yielding option names like the following:</span></div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">ExposedServerHiddenServiceEnable</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">PublicServerHiddenServiceEnable</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>But I'd be happy with any feature and option names that make it obvious that the hidden service server has reduced anonymity compared to standard hidden services.</div><div><div><br></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span style="background-color: rgba(255, 255, 255, 0);">teor</span></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span style="background-color: rgba(255, 255, 255, 0);">teor2345 at gmail dot com<br>pgp 0xABFED1AC<br><a href="https://gist.github.com/teor2345/d033b8ce0a99adbc89c5">https://gist.github.com/teor2345/d033b8ce0a99adbc89c5</a><br><br>teor at blah dot im<br>OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED</span></div></div></div></body></html>