Tim Wilson-Brown - teor:
On 23 Feb 2016, at 14:44, Fabio Pietrosanti (naif) - lists <lists@infosecurity.ch mailto:lists@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>