[tor-onions] Renaming Rendezvous Single Onion Services

[Tim Wilson-Brown - teor]

> On 23 Feb 2016, at 14:44, Fabio Pietrosanti (naif) - lists <lists at infosecurity.ch <mailto:lists at infosecurity.ch>> wrote:
> 
> On 2/23/16 4:14 AM, Paul Syverson wrote:
>> So every name's a problem. I think "Hidden Service" was a bad name in
>> hindsight in that it focused only on the location hiding and not on
>> the provided authentication, and worse, it facilitated stupid pundits
>> coining the misleading "Dark Web". That's why I like names like
>> "Single-Onion Service" and "Double-Onion Service" that describe the
>> technology not what it provides (which can also become a misnomer if
>> other features of the service become prominent in use).
...
> I think that anybody who configure a Tor for feature that Tor Project
> may consider risky from the Anonymity perspect, the right approach is to
> look forward what i wrote in this ticket
> https://trac.torproject.org/projects/tor/ticket/17019 <https://trac.torproject.org/projects/tor/ticket/17019> .
> 
> "For both NON-ANONYMOUS Tor Hidden Service use-cases (Server and
> Client), we can build them in the standard version of Tor by adding a
> command line like:
> 
> --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-client
> (tor2web mode)
> --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-server
> (encrypted services)"
> 
> That way:
> - The feature could be described as Paul is suggesting, by it's
> technical functionality
> - The end-user configuring will be prevented from making mistakes that
> may jeopardize it's anonymity

We discussed requiring a separate build for Single Onion Services, and initially rejected it in favour of a long option name containing "NonAnonymous".

But it does provide an extra layer of protection for hidden service operators, and it's quite easy to implement - the way the code is abstracted at the moment, we could add a few lines of code, and it would be done. I'll ask Nick and others wha they think in Valencia.

But the name still remains an issue - it needs to be memorable, and describe a critical feature/technology, like "Hidden Service" and "Tor2web".

I agree with Paul, features should describe technology wherever possible, and not single out one feature among many. But in this case, we want the name to remind people that location-anonymity isn't property of these services. Perhaps we do need a special build?

If we do end up choosing a feature-based name, I think we could start with a base name like:
(With credit to a thesaurus antonyms section...)
* Visible Service
* Obvious Service
* Overt Service
* Open Service
* Revealed Service
* Known Service

Then we could add "Onion" to distinguish Tor services when necessary in context.

We can also add:
* "Rendezvous", or
* "Extend" / "(OR)Port" to distinguish between the different onion services.

To be really explicit, we could add "IP Address": "Visible IP Address Service", "Known IP Address Service" - but I hope we can find a name where this is unnecessary.

I'm not entirely comfortable with any of these options, but I think they could get us close to a usable name that's easily memorable for onion service operators. (And perhaps those with media experience could steer us towards a name with fewer connotations.)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160225/26a853b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160225/26a853b6/attachment.sig>