Hello all,
Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problems with current terms are 1. '''Hidden''' and '''Dark''' have a negative connotations. 2. '''Hidden-service website''' is too long; '''hidden site''' is too vague. 3. '''.onion''' (read "dot onion") is hard to say and not very descriptive. 4. There is no general term for the set of available hidden services. 5. The term '''encrypted service''' is too general. This term refers to a setup (still needing development) in which Tor is required to connect to a service, but the service location is not hidden. Even without server anonymity, this setup can provide enforced client anonymity, secure name resolution, censorship circumvention, and end-to-end-encryption. Making the server location known can allow for improved performance (by shorter circuits) and security (by enabling location-aware path selection by the client).
We’ve come up with the following suggestions for better terms, which we’d like to offer up for discussion: 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. 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent).
We couldn’t decide on the best names for alternative onion service setups, because they don’t exist yet! But, we have some ideas about how these things might be named: 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 3. Some names to specify that a client connects to an onion service non-anonymously: * '''Client-direct access''' * '''tor2web mode'''
We’re maintaining an evolving wikipage with the above suggestions [1]. Some of us are already beginning to use the suggested terminology, to see how it works out. One nice goal might be for Tor to choose the new terms that it likes (if any) and use them in the rollout of next-gen onion services [2]. So we’re bringing up this subject now to a larger segment of the Tor community. Thoughts?
Best, Aaron
[0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten Loesing, and Paul Syverson [1] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminol... [2] https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
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?
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.
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.)
--Roger
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
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/Terminol...
On Feb 10, 2015, at 2:11 PM, Paul Syverson paul.syverson@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:
- '''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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: | Hello all, | | Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problem
| 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. | 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. | 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. | 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. | 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent). |
Have you done usability testing to see how people react to the onion terms, how explainable they are to non-technical journalists, or what connotations it might have across cultures?
My experience has been changing terminology is expensive and slow, and it's worth exploring lots of alternatives.
Adam
Good point. We (the Sponsor R group) have done no usability testing nor are we planning to. I don’t think we really have the time or skills for that, unfortunately. Maybe Tor more broadly has resources to put into a sophisticated re-branding effort. In any case, we do use these words every day and can make an intentional choice now. And for some things, words just didn’t even exist.
Best, Aaron
On Feb 10, 2015, at 2:22 PM, Adam Shostack adam@shostack.org wrote:
On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: | Hello all, | | Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problem
| 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. | 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. | 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. | 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. | 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent). |
Have you done usability testing to see how people react to the onion terms, how explainable they are to non-technical journalists, or what connotations it might have across cultures?
My experience has been changing terminology is expensive and slow, and it's worth exploring lots of alternatives.
Adam
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
A. Johnson wrote:
Several of us [0] working on hidden services have been talking about adopting better terminology.
In general, I am in agreement with this, but I wonder if now might be a good time to unify Tor terminology with other similar technologies like I2P and Cjdns/Hyperboria.
I have heard someone (forget who) propose that 'Dark Web' be dropped in favour of CipherSpace which could include all of these privacy perserving protocols, leaving terms like "OnionSpace" for Tor, "I2PSpace/EEPSpace" for I2P etc.
Cheers, Erik
On Wed, Feb 11, 2015 at 1:56 AM, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Several of us [0] working on hidden services have been talking about adopting better terminology.
In general, I am in agreement with this, but I wonder if now might be a good time to unify Tor terminology with other similar technologies like I2P and Cjdns/Hyperboria.
-
A. Johnson -
Adam Shostack -
Erik de Castro Lopo -
grarpamp -
Paul Syverson -
Roger Dingledine