Re: [tor-dev] Proposal #291 Properties (was IRC meeting)

[teor]

> On 25 Apr 2018, at 18:30, Mike Perry  wrote:
> 
> 1. Hidden service use can't push you over to an unused guard (at all).
>  2. Hidden service use can't influence your choice of guard (at all).
>  3. Exits and websites can't push you over to an unused guard (at all)
>  4. DoS/Guard node downtime signals are rare (absent)
>  5. Nodes are not reused for Guard and Exit positions ("any" positions)
>  6. Information about the guard(s) does not leak to the website/RP (at all).
>  7. Relays in the same family can't be forced to correlate Exit traffic.

I think this list is missing some important user-visible properties, or it's
not clear which property above corresponds to these properties:

* Is Tor reliable and responsive when guards go down, or when I move
  networks, or when I have lost and regained service?

I also think it's missing an implicit property, which we should make explicit:

* Can Tor users be fingerprinted by their set of guards or directory guards?

Perhaps this property is out of scope.

T
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal #291 Properties (was IRC meeting)

[Mike Perry]

George Kadianakis:
> Mike Perry  writes:
> 
> > Mike Perry:
> >> Mike Perry:
> >> > Heyo.
> >> > 
> >> > We're going to have a meeting to discuss Proposal 291. See this thread:
> >> > https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
> >> 
> >> 3. Describe adversary models for our variant proposals from the notes.
> >>(Why do we disagree? In Mike's case, my disagreements are because I
> >> think each step is an improvement over previous/status quo -- we can
> >> decide harder things later and still do better both now and later.)
> >
> > Ok, in the interest of getting closer to an adversary model, let's first
> > start with enumerating the properties the proposals below provide.
> > Properties #1-5 have parenthesis at the end of them.  When the condition
> > in parenthesis is met for property #N, we'll call that "strong #N".
> >
> 
> Thanks Mike for this email. I think this moves us forward quite a bit
> with an adversary model here! Here is some feedback:
> 
> >   1. Hidden service use can't push you over to an unused guard (at all).
> >   2. Hidden service use can't influence your choice of guard (at all).
> 
> Can we have a bit of more detailed description about the two properties above?
> (2) seems like a superset of (1), so making these properties clear would be 
> useful.

Yes, if a defense provides #2, then it always provides #1. Also, a
defense provides #1 without providing #2 (by using two guards equally,
for example).

Or said a different way, an attacker who can break #2 can sometimes use
that to break #1. 

To avoid confusion, I don't think we should change the property wording
or numbering until we do another round of proposal comparison, and/or
until people propose new properties that some designs satisfy (or
failed to satisfy).
 
> >   3. Exits and websites can't push you over to an unused guard (at all)
> >   4. DoS/Guard node downtime signals are rare (absent)
> 
> Also, what does property (4) mean exactly?

Property 4 is the best argument for using two guards as opposed to only
fiddling with restrictions. With the current way we handle onionskin
failure (#25347), clients will simply lose connectivity by way of
endless DESTROY responses before making a valid circuit. This means that
the adversary can onionskin-DoS guard nodes one at a time, and wait for
a hidden service to become unresponsive. That is what it means to have a
DoS (or downtime) signal.

Using two guards dumbly makes this rare. Both are down at the same time
by chance much less frequently than one is down, and a two-node DoS
search is harder to pull off when the adversary has to keep pairs (or
more) nodes offline at the same time, without taking other services
offline and causing false positives.

Using additional guards as soon as things fail makes these signals
absent, in theory. If a client is always trying to connect to new
guards, as long as the client can connect to the network, it will find a
guard that works pretty soon. This is also be another way of using two
guards dumbly, though.

> >   5. Nodes are not reused for Guard and Exit positions ("any" positions)
> >   6. Information about the guard(s) does not leak to the website/RP (at 
> > all).
> >   7. Relays in the same family can't be forced to correlate Exit traffic.
> >
> 
> Also it might be useful to rate the current guard design with these
> properties and see how well we are currently doing.
> 
> IIUC, since we use all the primaries for dirguards it provides:
>   1. Hidden service use can't push you over to an unused guard (at all).
>   3. Exits and websites can't push you over to an unused guard (at all)

If by current design, you mean the current network as-is without
changing any consensus parameters, then these two aren't provided.

Since the current design is "num primary guard to use"=1, the current
design tries really hard to use only this guard. This means that as soon
as a hidden service chooses that guard as it's RP, it will use a second
guard. This second guard is normally unused. Hence: Hidden service use
pushed the service over to an unused guard.

Similarly, if website can cause a client to keep connecting through
different circuits over and over (via at least 3 different attacks,
mentioned in the other thread), then it can eventually cause that client
to use a second guard. We want to fix this for other reasons (guard
discovery), but that doesn't change it as a property here. And there may
be more like them if we fix just these three.
 
> Because of the path restrictions it also provides:
>   5. Nodes are not reused for Guard and Exit positions ("any" positions)
>   7. Relays in the same family can't be forced to correlate Exit traffic.

Correct. It does provide these.
 
> It does *not* provide
>   2. Hidden service use can't influence your choice of guard (at all).
>   4. DoS/Guard node downtime signals are rare (absent)
>   6. Information about the guard(s) 

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

[Paul Syverson]

Thanks teor for spelling things out in moderate detail and Steph for
commenting.  

My tl;dr is to basically concur with everything they both said:  The
further from user-facing and the more embedded down in the codebase,
variables, code comments, controller commands, etc. the less important
to spend effort eliminating such vestiges from existing text. Going
forward, certainly any code comments and e.g. any commands that won't
break things should use current terminology.

aloha,
Paul

On Thu, Apr 26, 2018 at 11:07:27AM -0400, Stephanie A. Whited wrote:
> Hi!
> 
> Thanks for adding me to the thread.
> 
> 
> On 4/26/18 3:34 AM, teor wrote:
> > Hi All,
> >
> > There seems to be some confusion in this thread about the
> > current state of the hidden service to onion service name transition.
> >
> > So I'm going to describe the state of things as they are, then try to
> > describe what would need to be done.
> >
> > I'd also appreciate feedback from Steph and others on our priorities for
> > transitioning to the onion service name. I think we have been prioritising
> > user-facing text. (The blog, website, Tor Browser, metrics,  etc.)
> Yes, user, funder, and press facing text has consistently been using
> onion services at least since I've been on board. When I first joined,
> the message to me was that this was changed a couple years prior but
> changeover had been slow. I realize now a lot of folks didn't get that
> message.
> 
> We have already, with the help of Kat, updated hidden to onion services
> where possible on the website. I think the exception to this is older
> blog posts.
> 
> I realize it is not as easy to change some of the other elements, like
> the directory protocol, but I think it's important to make what changes
> are possible. I think it'd have a very positive impact to see these
> through.
> 
> Being aligned will help us build trust with the press, new users, etc.
> There are several reasons the name changed, if it is helpful to share
> more about that lmk.
> 
> >
> > Is this a sensible way of prioritising things?
> >
> > On 26 Apr 2018, at 16:42, Paul Syverson  > > wrote:
> >
> >>> Have OnionService aliases for controller commands, events, 
> >
> > These are current called "hidden service" or an abbreviation.
> >
> > Tor could add an alias mechanism for controller commands, events,
> > and fields, and use it to do the rename:
> >
> > https://trac.torproject.org/projects/tor/ticket/25922
> > 
> >
> > I don't think they are as high a priority as the torrc options and man
> > page.
> >
> >>> descriptor
> >>> fields
> >
> > These are currently called "hidden service", or an abbreviation.
> >
> > Descriptor fields are part of the directory specification and
> > implementation, and they are highly technical. So I'm not sure we gain
> > much from aliasing them or renaming them.
> >
> > Similar arguments might apply to other codebases:
> > * Onionoo
> > * stem
> > * consensus health
> > * Tor (network daemon)
> >
> > But the following user-facing applications should add documentation or
> > change names, if they haven't already:
> > * Relay Search / metrics website
> >   * uses HSDir for relay search, because that's what it's called in the
> >     directory protocol
> >   * uses "onion service" for statistics
> > * Tor Browser
> >   * uses "onion site"
> > * the Tor website
> > * new tor blog posts
> Website and new posts are covered.
> >
> >>> and anything else referencing 'HS' or 'HiddenService'.
> >
> > We considered adding OnionService* torrc option aliases for every
> > HiddenService* option in 0.2.9. But we deferred that change because we
> > ran out of time.
> >
> > All we need to do is add some new entries in the alias table, then do a
> > search and replace in the tor man page:
> > https://trac.torproject.org/projects/tor/ticket/17343
> >
> >>> 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
> >
> > That's a good question.
> >
> > OS conflicts with "operating system", so we could use:
> > * Onion
> > * OnSrv
> > * no abbreviations
> > Or any other colour you want to paint the bikeshed.
> >
> > To avoid an endless discussion, let's leave the decision to
> > the people who write, review, and merge the code.
> >
> >>> 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.
> >
> > torrc options, the tor man page, and the v3 onion service code
> 

Re: [tor-dev] Proposal #291 Properties (was IRC meeting)

[George Kadianakis]

Mike Perry  writes:

> Mike Perry:
>> Mike Perry:
>> > Heyo.
>> > 
>> > We're going to have a meeting to discuss Proposal 291. See this thread:
>> > https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
>> 
>> 3. Describe adversary models for our variant proposals from the notes.
>>(Why do we disagree? In Mike's case, my disagreements are because I
>> think each step is an improvement over previous/status quo -- we can
>> decide harder things later and still do better both now and later.)
>
> Ok, in the interest of getting closer to an adversary model, let's first
> start with enumerating the properties the proposals below provide.
> Properties #1-5 have parenthesis at the end of them.  When the condition
> in parenthesis is met for property #N, we'll call that "strong #N".
>

Thanks Mike for this email. I think this moves us forward quite a bit
with an adversary model here! Here is some feedback:

>   1. Hidden service use can't push you over to an unused guard (at all).
>   2. Hidden service use can't influence your choice of guard (at all).

Can we have a bit of more detailed description about the two properties above?
(2) seems like a superset of (1), so making these properties clear would be 
useful.

>   3. Exits and websites can't push you over to an unused guard (at all)
>   4. DoS/Guard node downtime signals are rare (absent)

Also, what does property (4) mean exactly?

>   5. Nodes are not reused for Guard and Exit positions ("any" positions)
>   6. Information about the guard(s) does not leak to the website/RP (at all).
>   7. Relays in the same family can't be forced to correlate Exit traffic.
>

Also it might be useful to rate the current guard design with these
properties and see how well we are currently doing.

IIUC, since we use all the primaries for dirguards it provides:
  1. Hidden service use can't push you over to an unused guard (at all).
  3. Exits and websites can't push you over to an unused guard (at all)

Because of the path restrictions it also provides:
  5. Nodes are not reused for Guard and Exit positions ("any" positions)
  7. Relays in the same family can't be forced to correlate Exit traffic.

It does *not* provide
  2. Hidden service use can't influence your choice of guard (at all).
  4. DoS/Guard node downtime signals are rare (absent)
  6. Information about the guard(s) does not leak to the website/RP (at 
all).

Let me know if I messed it up.

Clearly since everyone in this thread wants to improve the current
situation, the properties the current system lacks are important. In
particular it seems like (2) and (6) are particularly important properties.

>> Roger's proposal:
>> * Remove /16 and family path restrictions between guard and last hop
>> * Optionally, dir auths don't give you Guard if you're an Exit
>> * Use first guard but pad to backup guard so the switch isn't as obvious
>> * First and backup guard are chosen in different /16's and different families
>
> Depending on how good the padding is, this proposal maybe-provides:
>   1. Hidden service use can't push you over to an unused guard (at all).
>   3. Exits and websites can't push you over to an unused guard (at all)
>
> Depending on how good the detection mechanism is:
>   4. DoS/Guard node downtime signals are much more rare (absent)
>
> It provides strong:
>   5. Nodes are not reused for Guard and Exit positions ("any" positions)
>
> It provides:
>   7. Relays in the same family can't be forced to correlate Exit traffic.
>

How does it provide 7?

>
> 
>
>> Aaron's proposal:
>> * Use first guard but pad to backup guard so the switch isn't as obvious
>> * First and backup guard are chosen in different /16's and different families
>
> Depending on how good the padding is, this proposal maybe-provides:
>   1. Hidden service use can't push you over to an unused guard (at all).
>   3. Exits and websites can't push you over to an unused guard (at all)
>
> Depending on how good the detection mechanism is:
>   4. DoS/Guard node downtime signals are much more rare (absent)
>
> It provides strong #5:
>   5. Nodes are not reused for Guard and Exit positions ("any" positions)
>
> It provides #7:
>   7. Relays in the same family can't be forced to correlate Exit traffic.
>
> It does not provide #2 or #6:
>   2. Hidden service use can't influence your choice of guard (at all).
>   6. Information about the guard(s) does not leak to the website/RP (at all).
>  

How come Aaron's proposal provides the same benefits as Roger's even tho
they different? Am I missing something?

> 
>
> Ok, so here's a proposal that gets strong #1-4, and regular #5-7. It is
> my current favorite:
>
>>  * Set "num primary guards"=2 and "num primary guards to use"=2
>>  * Don't give Exit nodes the Guard flag.
>>  * Allow "same node, same /16, same family" between guard and last hop,
>>but only for HS circuits (which are at least 4 hops long for these
>>

[tor-dev] sbws meeting notes 26 April 2018

[Matt Traudt]

Next meeting is 3 May 2018 at 0930 UTC.

http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-26-09.59.html

https://pad.riseup.net/p/6292yqhUOuHC (copy/pasted below)

Simple Bandwidth Scanner Meeting 25 April 2018
==

This pad:
https://pad.riseup.net/p/6292yqhUOuHC

Previous week's notes:
https://lists.torproject.org/pipermail/tor-dev/2018-April/013084.html


Witty quote

- Unknown





Updates
===

pastly:
   last 7 days:
   - sbws is now open source

   https://github.com/pastly/simple-bw-scanner

   https://sbws.readthedocs.io/en/latest/

   - fix some bad bugs in 'sbws cleanup' command while writing tests for it
   - integrate with Travis CI and automatically test against python 3.4,
3.5, and 3.6
   - integrate with Read the Docs
   - gather intel on the environments our users will be running sbws in


https://github.com/pastly/simple-bw-scanner/wiki/Information-regarding-sbws's-target-user-base

   - did some research regarding library support for various distros.
incomplete
   - remvoe filelock dependency
   - brainstorm what I think a switch to http(s) should look like

   https://sbws.readthedocs.io/en/latest/proposals/001-switchtohttp.html

next 7 days:

- start implementing the switch to http(s)

- verify sbws works with library versions that aren't the absolute
newest

misc notes section (not udpates)

juga's tor tickets:
https://trac.torproject.org/projects/tor/query?status=!closed=%7Ejuga


juga:
  Not sure which week was (since we changed from Monday to Thursday):
  - review, comment on debug option not being used #85
  - add logging conf to log to file/system #87
  - review Periodically test reachability of helpers #93
  - create issue Include file where to write ``generate`` results in
the config #91
suggest having options both in config and cli and cli overriding
conf
  - report about problem with init and helpers #95
  - create issue about adding software to header #96
  - review using kilobytes #97, #98

  Past week:
  - fix conf issues locally and in testnet after "megacommit"
  - more changes on the spec, after new teor review
https://github.com/torproject/torspec/pull/4/commits/54ef4d4355d2b475466bf11e80ad4bc57c7e7ec3
  - create improve deployability #99
  - create issue Debian package #101
  - Work on issue software and sofware_version in v3bw files #112
  - create issue Include coverage in travis #117
  - create issue Include travis and coverage badges in README
enhancement #118

  Next week:
  - debug what tor does to solve
https://github.com/torproject/torspec/pull/4/#issuecomment-384555243
  - review the software/version ticket according to results from
previous (https://github.com/pastly/simple-bw-scanner/issues/96)
  - review spec according to results from previous
  - add a default output file for generate that can be overriden by
cli args (https://github.com/pastly/simple-bw-scanner/issues/91)
  - improve deployability, this should also help to update instances
running in testnet (https://github.com/pastly/simple-bw-scanner/issues/99)
  - update version sbws running in testnet

Things to communicate:

 - i put as date of sbws release 1.0.0 (milestone 1) 1st May, but
i'd postpone

   to later so that we've more time testing and fixing last details

 - teor, can i make public the list of tasks you've proposed for
SoP?, any place you would propose?

 - pastly: It's fine to close issues/PRs you think aren't apropiate
for any reasons, but please say so before closing (#111, #87)

 - i stop attending net-team meetings until we need to disscuss
something there that we don't discuss in this meeting


List of tasks for 3 months proposed by T. (19th Apr)


- implement features we wanted in torflow in sbws instead (1 week)
  - bwauth code needs to be smarter about failed circuits
https,//trac.torproject.org/projects/tor/ticket/16559
  - assign the 10-second client timeout as the time for failed circuits?

  - at least publish failure rates
https,//trac.torproject.org/projects/tor/ticket/7281

  - Understand how accurate the bandwidth authority estimates are
https,//trac.torproject.org/projects/tor/ticket/7177
- integration tests (1 week)
- a practice transition in the test network (1 week, but split up)
  - set up torflow
  - set up sbws

  - compare and switch
- work little-t tor needs (3 weeks)
  - report version of bwscanners in votes
https,//trac.torproject.org/projects/tor/ticket/3723
  - stop relays reporting zero observed bandwidths
https,//trac.torproject.org/projects/tor/ticket/24250
  - relays should regularly do a larger bandwidth self-test
https,//trac.torproject.org/projects/tor/ticket/22453
  - bandwidth testing circuits should use guards sometimes

Re: [tor-dev] onion v2 deprecation plan?

[George Kadianakis]

nusenu  writes:

> Hi,
>
> even though you are probably years away from deprecating onion v2 services
> it is certainly good to have a clear plan.
>
> I'm asking because the sooner onion v2 are deprecated the sooner some 
> people can stop worrying about malicious HSDirs.
>

Yes indeed. The sooner we deprecate v2 the sooner we can stop worrying
about malicious HSDirs. And also we will be able to reduce the
requirements for becoming an HSDir which will strengthen and make our
network more robust.

That said, I think we are unfortunately still far from deprecating v2
onions:

The first actual step to v2 deprecation, is to make v3 the default
version.  But to get there, we first need to solve various bugs and
issues with the current v3 system (#25552, #22893, #23662, #24977,
etc.).  We also need to implement various needed features, like offline
keys (#18098), client-authorization (#20700 ; WIP 
https://github.com/torproject/tor/pull/36),
control port commands like HSFETCH (#25417) and revive onionbalance for
v3.  We might also want to consider possible improvements to the UX of
long onion names (like #24310) 
(https://blog.torproject.org/cooking-onions-names-your-onions).

After we do most of the above, we can turn the switch to make v3 the
default, and then we need to wait some time for most of the users to
migrate from v2 to v3. After that we can initiate the countdown, and
eventually deprecate v2s for real.

It's hard to provide an actual timeline for the above right
now. However, we are currently applying for some onion-service-related
grants, and hopefully if we get them we will have the funding to
accelerate the development pace.

Cheers!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] minor website update request: have the tor-relay guide ready for Ubuntu 18.04

[teor]

Hi Hiro,

> On 26 Apr 2018, at 18:31, nusenu  wrote:
> 
> For that I submitted an update on trac [1] a few days ago.
> From my personal experience, my website update requests (also trivial ones)
> take about two months to get committed, it would be great if we could speed
> things up for this specific request to have the relay guide ready for the 
> new Ubuntu LTS nearly at the same time when the release is happening.
> (I won't be bothering you with non-tor-relay-guide related website
> updates anymore).

I want to make sure we encourage patches to the website.

Who has the ability to merge website patches?
Why does it take so long?
Is there any way we can make it easier for you all?

T
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] minor website update request: have the tor-relay guide ready for Ubuntu 18.04

[nusenu]

Hi,

I wanted to have the tor relay guide ready for the
new Ubuntu LTS version 18.04 nearly at the same time when it is
released.

Thanks to the torproject debian maintainer we already have packages
for bionic.

Basically the only thing that is missing is the website update to
include the new distro for the sources.list generator.

For that I submitted an update on trac [1] a few days ago.
From my personal experience, my website update requests (also trivial ones)
take about two months to get committed, it would be great if we could speed
things up for this specific request to have the relay guide ready for the 
new Ubuntu LTS nearly at the same time when the release is happening.
(I won't be bothering you with non-tor-relay-guide related website
updates anymore).

thanks,
nusenu 


[1] https://trac.torproject.org/projects/tor/ticket/25888

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

Hi All,

There seems to be some confusion in this thread about the
current state of the hidden service to onion service name transition.

So I'm going to describe the state of things as they are, then try to
describe what would need to be done.

I'd also appreciate feedback from Steph and others on our priorities for
transitioning to the onion service name. I think we have been prioritising
user-facing text. (The blog, website, Tor Browser, metrics,  etc.)

Is this a sensible way of prioritising things?

On 26 Apr 2018, at 16:42, Paul Syverson  wrote:

>> Have OnionService aliases for controller commands, events,

These are current called "hidden service" or an abbreviation.

Tor could add an alias mechanism for controller commands, events,
and fields, and use it to do the rename:

https://trac.torproject.org/projects/tor/ticket/25922

I don't think they are as high a priority as the torrc options and man page.

>> descriptor
>> fields

These are currently called "hidden service", or an abbreviation.

Descriptor fields are part of the directory specification and
implementation, and they are highly technical. So I'm not sure we gain
much from aliasing them or renaming them.

Similar arguments might apply to other codebases:
* Onionoo
* stem
* consensus health
* Tor (network daemon)

But the following user-facing applications should add documentation or
change names, if they haven't already:
* Relay Search / metrics website
  * uses HSDir for relay search, because that's what it's called in the
directory protocol
  * uses "onion service" for statistics
* Tor Browser
  * uses "onion site"
* the Tor website
* new tor blog posts

>> and anything else referencing 'HS' or 'HiddenService'.

We considered adding OnionService* torrc option aliases for every
HiddenService* option in 0.2.9. But we deferred that change because we
ran out of time.

All we need to do is add some new entries in the alias table, then do a
search and replace in the tor man page:
https://trac.torproject.org/projects/tor/ticket/17343

>> 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

That's a good question.

OS conflicts with "operating system", so we could use:
* Onion
* OnSrv
* no abbreviations
Or any other colour you want to paint the bikeshed.

To avoid an endless discussion, let's leave the decision to
the people who write, review, and merge the code.

>> 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.

torrc options, the tor man page, and the v3 onion service code
mainly use "hidden service", and sometimes use "onion service".

I don't see much value in changing the code.

If we decide there is value in changing the torrc options and man page,
we need to allocate a few days of work on the roadmap to make it
happen.

>> 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'.

That's not the current state of the tor network daemon v3 onion service
code, specs, options, and man page. They use a mix of terminology
(see above).

> 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'.

We have gradually been using onion services in new documentation and
specs, since "single onion services". But we haven't changed existing
code and documentation.

> This 

Re: [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