[tor-onions] Renaming Rendezvous Single Onion Services

[Ann O'Nymous]

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

Why did you reject separate builds? The use case for Single-Onion
Services is very different from traditional Double-Onion Services. And
potential consequences for accidentally using Single-Onion Services are
huge. Accidents happen. Stupidity happens. Perhaps someone is learning
and testing, and then goes to production with the wrong torrc. Or they
hire someone to code, and there is miscommunication. I agree with Fabio.
Requiring a custom build with a --very-hard-to-ignore-warning flag is
far stronger protection.

<trim>