[tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

[teor]

> Date: Fri, 10 Apr 2015 15:47:23 +0300
> From: George Kadianakis <desnacked at riseup.net>
> 
> David Goulet <dgoulet at 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-services.txt
>>> 
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150413/e1667f2f/attachment.html>