[tor-dev] Standardizing the 'onion service' name

[Paul Syverson]

On Wed, Apr 25, 2018 at 05:18:32PM -0700, Damian Johnson wrote:
> Hi all, teor suggested engaging the list with #25918 so here we go!
> Ticket #25918 has a couple goals...
> 
> 1. Provide a tracking ticket for the rename effort.
> 2. Come to a consensus on if we should move forward with "onion
> service" or revert back to "hidden service". The limbo we've been in
> for months is confusing for our users and we should standardize on a
> name.

I'm very confused why you say that this is not a long solved problem.
I see nothing in the recent posts about v2 deprecation that would in
any way change that, or even raise it as a topic.

When talking in general to people, the answer should be that they are
all (v2 and v3) onion services. That's it. I believe this is the
official position of the Tor Project, and they have worked hard to
make sure that this is reflected on any new materials on the site for
some time.  I'm cc'ing Steph in case she is not on the tor-dev list
and wants to say anything further on that point.

I'll respond to other comments inline below. Feel free to add my comments
to the ticket if you want, but IMO there is no reason a ticket should
exist at all for this.

> 
> Here's the ticket...
> 
> ========================================
> 
> A recent post on tor-dev@ just got me thinking about the roadblocks we
> have for v2 deprecation. There's a couple I don't believe we're
> following in trac so lets fix that.
> 
> For me the biggest is its name. Renaming takes work, and we attempted
> to rename hidden services in v3 without investing the time to make it
> happen. We should either fix that or revert to to the old name. To
> move forward we need to...

I don't understand this at all. We have renamed hidden services to be
called 'onion services' some time ago. I don't know what it is that
you feel we didn't make happen. 'Hidden services' was an old name for
onion services that has always been misleading narrow about the nature
of these services and thus long in need of replacing (and actually the
name we originally and for some time used was 'location hidden
services' though 'location' simply started getting more and more
ignored along the way).  "Misleadingly narrow" because some of their
central properties are ignored by calling them 'hidden services',
viz. the stronger and more-site-owner-controlled authentication these
services provide and their address lookup security vs. the less secure
parts of the internet served by DNS.

> 
> Have OnionService aliases for controller commands, events, descriptor
> fields, and anything else referencing 'HS' or 'HiddenService'.
> 
> Speaking of which, how do we plan to replace abbreviations? Having an
> 'OSFETCH' or 'OS_CREATED' event doesn't exactly have the same ring as
> their HS counterparts. ;P
> 
> Adjust all our docs to be consistent about the name.

Right, anything v3 should be consistently calling these 'onion
services'.  Variable names, etc. particularly those still in use in
code shared with v2, don't need to be changed. It is OK if such
vestiges of older usage remain in abbreviations, as long as the
description of them, e.g., in any new Tor proposal, describes them
with appropriately current terminology.

> 
> Renaming takes work. Lesson I learned from Nyx is that it works best
> if you draw a line in the sand and stand by it. With Nyx, version 2.0
> is called Nyx (you won't find any docs saying otherwise) and version
> 1.x is the legacy 'arm' project.
> 
> If I was in your shoes I'd opt for the same. Either prioritize the
> aliases and be firm that v3 are 'Onion Services' or abort the rename.
> Otherwise this will live in a confusing dual-named limbo land
> indefinitely. ;P

I'm prettty sure that v3 being 'onion services' has been the official
Tor Project position since at least half a year. We wouldn't be
aborting the rename, because 'abort' would imply it is not
complete. Anything now not using the current name is not part of an
incomplete process, it is simply wrong and outdated. Steph correct me
if I am wrong about that.

So I think you've answered your own question. Nothing in v3 should be
called 'hidden services'. And anything new in code and documentation
should be called 'onion services'. If you want to think of v2 and
earlier as 'hidden services' for purposes of understanding legacy
component and variable names, e.g., HSDir that's fine. And as such,
variable names, etc. in code that continues to be used for both v2 and
v3 can can persist. But again, any new specs, documentation, etc.
should call them 'onion services'.

This acceptance of existing v2 documentation calling them 'hidden
services' while refusing this for anything v3 is a little misleading
about when and why the naming transition happened, but its close
enough to serve as your line in the sand if you feel one is needed. 
I actually argued the value of essentially such a line-in-the-sand
position to Steph a while ago. This doesn't preclude also calling v2
and earlier 'onion services'. Indeed, it's not just OK but preferable,
for the above mentioned reasons.

aloha,
Paul