> I think new users might not appreciate the difference between similarly named > terms and then choose the wrong one to their detriment. It seems better that > they should later learn of shared technology that's not clear from the naming > differences than be surprised by differences in security properties that they > incorrectly assume from similar names. (Perhaps more generally, the naming > should reflect how users---broadly construed---should think about these > things rather than the mental models that are useful as developers.)
It is actually for usability that I dislike making unnecessary distinctions. “Onion service” makes it simple to clients: xyz.onion = service accessible only through Tor. And the problem for servers doesn’t seem so bad. Setup process: User: I’d like to set up an onion service. System: Would you like a hidden/protected/obfuscated onion service or a direct/exposed/peeled/flagrant service? Choose a direct service only if you want to expose the server location in order to improve performance [and security] for your clients. (Default: hidden service) User: I don’t like reading, I’ll just go with the default. The point is that these security/performance choices should not be exposed to the clients, but they can be safely exposed to server operators. Aaron _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
