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