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

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

On Wed, Feb 11, 2015 at 11:52:37AM +0000, str4d wrote:
> 
> Erik de Castro Lopo wrote:
> > 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.
> 
> It is interesting that you raise this, because we at I2P have been
> thinking the same thing. We discussed the issue of I2P terminology at
> 31C3 and decided that after 12 years of Tor/I2P coexistence, Tor had
> the upper hand with regard to commonplace terminology.
> 
> In our next release, we are changing most of our user-visible
> tunnel-related terms (I2P destination, tunnel, eepsite etc.) to
> instead use "Hidden services" in some way [0], to draw parallels to
> Tor hidden services - because as far as an end user is concerned, they
> do "pretty much" the same thing. And as far as we could tell, "hidden
> services" is now considered "too generic" for Tor [1], so it made
> sense to use it generically. Tags are now frozen for the 0.9.18
> release, but we are still open to further discussion about terminology.
> 

One of the problem with "Hidden Services" is that it focuses
exclusively on the hiding. But even existing deployed Tor onion
services provide other functions, such as traffic and site
authentication. Some of the future services we were discussing might
require access come through Tor but not hide the server at all. All of
these different properties are about providing for traffic and
routing, security properties that are commonly understood for data
(e.g., confidentiality,authentication,integrity). Tor, and I think
I2P, tend to focus on traffic and route confidentiality, which is more
commonly called anonymity when thinking about the client and hidden
services when thinking about the server. Thus, for a truly more
general term I would suggest 'traffic security', which is what I have
called this class of security properties for some time.

> > 
> > 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.
> 
> I am certainly in favor of this kind of collaborative approach. It's
> hard enough already trying to make this stuff understandable to end
> users (usability and UX of the tools themselves aside), without having
> multiple kinda-similar-but-not tools trying to do so in different
> ways. A "united concept front" would benefit tools _and_ users.
> 

+1 

although the current purpose was not to come up with an alternative to
"Dark Web" since that should die as a misguided attempt to glom
together multiple technical concepts not just a loaded pejorative term
for a clear technical concept. As such it is simply the things that
can be reached by .onion addresses over Tor that we were trying to
improve the terminology for, not the more general properties. Cf. my
above suggestions for my take on that.

aloha,
Paul
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev