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

[Aaron D. Jaggard]

> On Apr 20, 2015, at 1:40 PM, Paul Syverson <paul.syverson at nrl.navy.mil> wrote:
> 
> On Mon, Apr 20, 2015 at 01:05:16PM -0400, A. Johnson wrote:


>>> This is another reason why [modifier] onion service is
>>> problematic; it will almost certainly get shortened in use, just
>>> as location-hidden service did.
>> 
>> The obvious and suggested shortening (i.e. omitting the word
>> “onion”) works well, in my opinion.
> 
> What then was wrong with clientside service, or evn client service?
> (Although I am again increasingly sour on the idea of trying to treat
> these and heretofore "hidden" services as somehow broadly the same
> animal.)
> 
>> 
>>> Here's one suggestion: must-tor service (or mustor service if we want
>>> to be even more compressed.
>> 
>> This reminds me of the “Tor-required service” suggestion you
>> initially made. I dislike like it for the same reasons, the primary
>> one of which is that it uses two entirely separate names for
>> services that actually will probably indistinguishable to the
>> user. That’s why I like the “onion services” umbrella over both
>> hidden and fast/direct/exposed/public/peeled/etc.
> 
> 
> Thank you for making my point. My fundamental concern is that these
> are two separate services with important differences. We will use the
> same (or too similar) names for them, and the user will be confused
> about which s/he is using. (Note that user here includes the Tor user
> setting up the service, not just the one who is the client of that
> service. Also those doing subsequent design and analysis are very much
> steered by terminological choices "anonymity", "hidden", etc.)  

I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment.  It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names.  (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.)

Best,  adj