[tor-onions] Renaming Rendezvous Single Onion Services

Tim Wilson-Brown - teor teor2345 at gmail.com
Wed Mar 30 00:56:34 UTC 2016


> On 10 Mar 2016, at 07:22, Roger Dingledine <arma at mit.edu> wrote:
> 
> On Wed, Mar 09, 2016 at 03:02:08PM -0500, Paul Syverson wrote:
>> Well I remain completely opposed to anything conveying intent and regard
>> that as just a mistake for our purposes.
> 
> Agreed.
> 
> What happened here? There's a huge thread, which is just rehashing
> discussions that other people had already over the last year? And it
> looks like teor started the thread on behalf of one line that Nick said
> on irc? And Nick probably doesn't even know that a tor-onions list exists?

Nick's concern was that users could configure Single Onion Services without realising that it provides no server location anonymity.

I initially thought we could change the torrc option name to make this clear.
But the discussion turned into changing the public name of the feature as well (which wasn't my original intention).
I'm sorry that I kept the discussion going, without stepping back to look at the initial purpose of the discussion.

I now believe that trying to overload the name of a feature with warnings about its downsides was a mistake.
I also believe that we have a perfectly good name for the feature that's been in use for almost a year now: "Single Onion Services".
Unless there's some compelling reason we can't use that name, I propose that we keep it.
(I can't remember a compelling reason to change a year-old name in the discussion so far.)

This would mean that Single Onion Service operators would include in their torrc:

SingleOnionMode 1
HiddenServiceDir …

(If we ever have multiple SingleOnionMode implementations, such as rendezvous and extend, we can modify the option to take mode names: "rend", "extend". We could migrate to the new names by making "1" an alias for "rend".)

As a separate issue, I think there are two alternative designs that can prevent users from configuring the feature and then exposing their location unintentionally:

Tor2WebMode requires users to add a compilation option: --enable-tor2web-mode
We could do this with Single Onion Services as well: --enable-single-onion-mode
If SingleOnionMode is configured without the compilation option, tor warns the user and refuses to start.
When it is configured, tor warns the user they're non-anonymous, then starts.
However, using a compilation option makes the feature harder to test.
And Tor2Web operators already don't like having to compile separate binaries.
It's likely Single Onion operators would feel similarly.

Alternately, we could add a torrc option: NonAnonymousMode
If SingleOnionMode is configured without NonAnonymousMode, tor warns the user and refuses to start.
When it is configured, tor warns the user they're non-anonymous, then starts.

I spoke with Nick on IRC and he's happy with either of these options.

I'd like to proceed with the NonAnonymousMode torrc option, unless there are compelling reasons against that design.
I hope that this will allow us to get SingleOnionMode merged early in tor 0.2.9.

> This seems like a good opportunity for somebody to put all of the good
> thoughts on this topic into one place, so everybody here can get up
> to speed and be able to contribute new things if they have them, and
> so future people can get up to speed too (so we don't do this again in
> 6 months).
> 
> Anybody want to take that on?
> 
> Otherwise this thread is just going to get worse. :)

I can't take on updating (or creating) a wiki entry right now.

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/20160330/3893a253/attachment-0001.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/20160330/3893a253/attachment-0001.sig>


More information about the tor-onions mailing list