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.
- fast onion service
- exposed onion service
- direct onion service
- peeled onion service
- 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