[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



> I've been hesitant to weigh in on the naming conversation for hidden services. But I am concerned about the issues raised in the previous few emails on the topic.
> 
> Matt @ Speak Freely has a strong point about acronym collisions - they only serve to confuse users and dilute the search space. And usability becomes a security issue as soon as names are confusing to users.

I agree that it is helpful to have a unique acronym. However, I think that a more important naming principle (and one that has been omitted) is:
  4. Names should be easy to use
The suggestions (Client Anonymous Hidden Services, Exposed Server Hidden Services, Public Server Hidden Services) are all very long and not something that I would like to regularly use in conversation (oral or written). I would also argue that these suggestions violate 3A, in that direct onion services are not âhidden servicesâ at all.

As far as âdirect onion servicesâ not describing which end is anonymous, I agree that a more descriptive term could be useful. The terms âserver-direct onion serviceâ or âserver-known onion serviceâ would satisfy this. Those are as long as the suggestions that you made, and so not great for regular use, but I can see such terms being used occasionally when clarity is important.

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