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

A. Johnson aaron.m.johnson at nrl.navy.mil
Tue Feb 10 20:09:12 UTC 2015


Roger, your suggestion to prefer “onion service” regardless of any client or server short-circuiting is in line with our suggestions. When server-short-circuiting becomes an actual thing, then Paul may argue that a different name is appropriate (depending on if it uses an onion address, as I understand him), but that depends on the specifics of the design.

As far as the “short-circuit” term itself, I personally think its cute and logical but a bit long (“server short-circuited onion service”?). Maybe you can think of a way to shorten it. In any case, I added it to the wiki [0]. My opinion is that no good recommendation can be made until there is a design, and the person that writes the design will probably get a big say in the name. I believe that Steven Murdoch has a student working on it…

Best,
Aaron

[0] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology

> On Feb 10, 2015, at 2:11 PM, Paul Syverson <paul.syverson at nrl.navy.mil> wrote:
> 
> 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
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



More information about the tor-dev mailing list