Date: Fri, 10 Apr 2015 15:47:23 +0300 [snip]- We really really need a better name for this feature. I decided togo with "Direct Onion Services" which is the one that the NRL peoplesuggested here:https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.htmlI'm not super happy with it, but I can't think of better ones myself.Here are some candidates:1 Way Anonymous Hidden ServicesFast Onion ServiceShort-circuited Onion ServicesFast-but-not-hidden Services"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like itbecause it describes pretty much what it is and the acronym is FOSS. :) 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. Others have also made important points about how we name things in general. So I'd like to propose some general naming principles, mostly distilled from recent conversations about names: 1. Avoid acronyms that collide with popular acronyms, particularly those in the security / software / technology spaces. 2. Names should be kept consistent across the entire Tor code base and ecosystem. 3. When selecting option, feature, and concept names: A) Names should describe the most important user-visible impact of an option, feature, or concept. B) If the feature has a serious impact on anonymity (or other typical user assumptions), the name should indicate that. C) Names should avoid specific implementation details, as these may change. D) Names should avoid giving relative opinions on performance, security, or privacy impacts, as these are often dependent on context. E) Project names are an exception to principle 3, and should have abstract names, or descriptive acronyms. My evaluation of the suggestions around hidden services / onion services based on these principles is: Onion Service Collides with OS, or Operating System, violating principle 1: no collisions. 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.)
I'm concerned about the collisions with OS implied by these acronyms (1). 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). Fast-but-not-hidden Services 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? 1 Way Anonymous Hidden Services This is descriptive (3A & 3B), but which end is anonymous? Why not state that it's the client: Client Anonymous Hidden Services Or, even better, state that the server is non-anonymous: Exposed Server Hidden Services Public Server Hidden Services Yielding option names like the following: ExposedServerHiddenServiceEnable PublicServerHiddenServiceEnable 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. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED |
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev