Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
Date: Fri, 10 Apr 2015 15:47:23 +0300 From: George Kadianakis <desnacked@riseup.net>
David Goulet <dgoulet@ev0ke.net> writes:
On 09 Apr (21:58:49), George Kadianakis wrote: Hello,
I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted...
Feedback would be greatly appreciated. [snip]
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services
"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it because it describes pretty much what it is and the acronym is FOSS. :)
It's not clear to me why acronym collisions are a plus :)
- We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names.
This one depends on the name quite heavily but I don't think we should have a scary name. Scary name seems to me they will simply bring more questions without context of the actual feature. What is "Dangerous" about this, why is it in Tor at all?... This could simply be resolved by clear and thorough documentation of the risks/benefits of the options.
For instance, we could *not* put it in the default torrc file and thus will only be in the man page with *good* documentation. Like you said also in the proposal, a big warning is very important at boot.
If it's off by default and not present in the torrc file, there are no reasons why someone would enable this just because it's says "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are not that responsible for reckless HS operator ;)
Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK with changing the proposal to use 'DirectOnionServiceEnable' but I would prefer if it's a bit more alarming.
[snip]
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. 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.)
Direct Onion Service Dangerous Direct Onion Service
As it's already been noted, these collide with DOS and DDOS (1), and don't describe which end is direct (3A & 3B).
Fast Onion Service Short-circuited Onion Services
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
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.
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.
I agree that it is helpful to have a unique acronym. However, I think that a more important naming principle (and one that has been omitted) is: 4. Names should be easy to use The suggestions (Client Anonymous Hidden Services, Exposed Server Hidden Services, Public Server Hidden Services) are all very long and not something that I would like to regularly use in conversation (oral or written). I would also argue that these suggestions violate 3A, in that direct onion services are not “hidden services” at all. As far as “direct onion services” not describing which end is anonymous, I agree that a more descriptive term could be useful. The terms “server-direct onion service” or “server-known onion service” would satisfy this. Those are as long as the suggestions that you made, and so not great for regular use, but I can see such terms being used occasionally when clarity is important. Aaron
participants (2)
-
A. Johnson -
teor