Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

On Mon, Apr 20, 2015 at 08:51:59AM -0400, A. Johnson wrote:
> >> 
> >> Why not simply "onion service"?
> > 
> > Because we have already started using "onion service" to cover what we
> > previously called "hidden servicesâ
> 
> Right.
> 
> > My latest thinking about the terminology is that we should call them
> > something like "client side onion service" (CSOS, suggested
> > pronunciation C-sauce).
> 
> These suggestions are too long, in my opinion, and a short acronym
> cannot substitute for a short name. Of primary importance, I think,
> is that the name be easy to use and is meaningful. I like the
> [modifier]+"onion serviceâ approach, which can be further shortened
> to [modifier]+âserviceâ when the onion context is clear. This
> already works for âhidden serviceâ, which we can more clearly refer
> to using âhidden onion serviceâ. Some options following this pattern
> are

I agree with the above.

>   1. fast onion service
>   2. exposed onion service
>   3. direct onion service
>   4. peeled onion service
>   5. bare onion service
> 

I don't like any of these. They all fall into the same trap as "hidden
service" or another I'll set out momentarily. I was going to mention
these issues in my last message, but didn't wanted to focus on a
positive suggestion rather than go on too long about why I was
rejecting alternatives.


The problem with "fast", "direct", and maybe "bare" is that they
describe some property we're trying to provide with these. Like
hidden, I think the chance that they will evolve or be applied in some
way for which these terms won't apply is too great. Then we'll be
saying things like, "When this design was first proposed this was
considered a fast(direct) connection vs. what the previous onion
services design did. We now have foo, which is faster(more direct),
and we're using fast(direct) onion services for application bar which
is not actually very fast(direct) and we don't really care if it's
particularly fast(direct) for this application" etc. Think about the
extent to which hidden services are used for other things than serving
up web pages.

The problem with "exposed", "peeled", and maybe "bare" is that these
all imply that these are onion services that are diminished in some
way. I can just picture the paper titles and, worse, inflamatory news
headlines the first time someone shows some attack on some aspect of
the design (or more likely on something else entirely on a system that
is configured as such a service). I think anything implying vaguely
lesser onion services is unacceptable.

This is why I'd like to have a name that reflects exactly and only
what the system does, which is require that connections use
Tor. Actually the more I ponder this, the more I return to a point I
raised weeks (months?) ago that I'd just as soon not call it
[modifier] onion service, because if it ends up not having the .onion
domain name or requiring lookup in the HSdir system etc. it will be a
very confusing misnomer vs. what we are now calling onion services. I
thought I had accepted the [modifier] onion service approach, but I'm
going back to my former position.

As we've been discussing, long names are problematic, but the shorter
ones that may evolve can be even more problematic.  We originally
called hidden services "location-hidden services" which we tied back
to even earlier terminology noting in the original Tor design paper
"Rendezvous points are a building block for location-hidden services
(also known as responder anonymity)". The shortening to "hidden service"
was convenient for discussion, but lead to many of the problems we
now face. This is another reason why [modifier] onion service is
problematic; it will almost certainly get shortened in use, just
as location-hidden service did.

I think the best thing would be a neologism that, most importantly,
won't get abused or cause confusion because of some connotation of the
name.  Bonus if it will nonetheless make sense to anyone who knows the
system, and can be explained in a few simple words to anyone who
doesn't.

Here's one suggestion: must-tor service (or mustor service if we want
to be even more compressed. Either can also play off the idiomatic
connotation of only accepting those connections that pass muster, but
that's really secondary).  If someone knows even a little about Tor
(even if they've never heard of onion services or hidden services)
they can maybe guess what the service is about. If they know nothing
about Tor, saying that connections to this service must come through
the Tor network explains the name immediately, even to someone whose
next question is "What's the Tor network?".

Note that if mustor services also have .onion addresses I don't see
that as a problem at all. I could explain that too, but I'll stop here
for now.

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