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:
- '''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.
- 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
- 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