[tor-dev] A proposal to change hidden service terminology

[Paul Syverson]

On Tue, Feb 10, 2015 at 01:41:35PM -0500, Roger Dingledine wrote:
> On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote:
> > 	1. '''onion service''' should be preferred to refer to what is now called a "hidden service". If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction.
> 
> I'm a fan.
> 
> > 	1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol:
> > 		* '''Tor-required service''', '''TRS''' for short
> > 		* '''Direct onion service''', '''direct service''' for short
> > 	2. Some names to specify that the onion service is hidden, if that becomes necessary:
> > 		* '''Protected onion service''', '''protected service''' for short
> > 		* '''Tor-protected service''', '''TPS''' for short
> 
> You know how we call "a person who makes an anonymous Facebook account
> over Tor and uses it without ever identifying herself to Facebook"
> a Tor user? And how we also call "a person who logs into her 'real'
> Facebook account over Tor" a Tor user?

Yes and?

> 
> I think for more onion service scenarios than we think, we should
> just call them onion services and not specify which components of the
> rendezvous process are short-circuited and which aren't.

The idea of a TRS/direct-onion-service/etc as we have been discussing
it is a service where there is in all likelihood no rendezous (nor
introduction point) at all.  It is just necessary to connect to it via
Tor. A naive way to implement this would be to have a server that only
accepts connections from Tor relays (OK we could even require only Tor
relays and only TLS).  Presumably we want a somewhat smarter design
than that. I don't want to set out anything smarter here. My goal is
just to give the basic notion simply if not entirely accurately.  The
point is that it is an open question (that would be foolish to answer
until the design and its use are more fully set out) whether we would
want to give these .onion addresses (or force them to have .onion
addresses to work with the protocol). And if they don't have (or only
optionally have) .onion addresses, then calling them onionsites seems
like a bad idea that can only foster confusion with the things that do
have .onion addresses.  And to give them .onion addresses just so we
can apply the currently proposed terminology would be to do things
bass ackwards.

The current terminological proposal works well for heretofor "Hidden
Services" and associated protocols and systems, even (and perhaps
especially) when used for other purposes than hiding IP address of the
service. What best to call these other future kinds of services at
this point is quite bikeshed IMO.

> 
> And for those situations where we're specifically talking about whether
> the rendezvous process is short-circuited on the client side and/or the
> service side... I wonder what people think of this 'short-circuited'
> term. (It is both an English idiom and also actually true.)

Perhaps that will be good. Again I'd like to know what the design is
doing before I try to name it.

aloha,
Paul