Re: [tor-bugs] #21284 [Core Tor/Tor]: Add torrc option for non-anonymous SocksPort

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21284: Add torrc option for non-anonymous SocksPort
--------------------------------------------+------------------------------
 Reporter:  teor                            |          Owner:
     Type:  enhancement                     |         Status:  new
 Priority:  Very Low                        |      Milestone:  Tor: very
                                            |  long term
Component:  Core Tor/Tor                    |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  tor-hs, single-onion, wontfix?  |  Actual Points:
Parent ID:                                  |         Points:  1
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------

Comment (by teor):

 Replying to [comment:6 alecmuffett]:
 > In terms of use cases, the goal is to simplify OnionBalance adoption to
 drive scale; anyone who is running Single Hop Circuits is unlikely to care
 about remaining anonymous, so it seems odd to ban them from SOCKS merely
 to drive the point home?

 As s7r noted, Exits already ban single-hop circuits, so if we had naïvely
 allowed a single-hop SOCKSPort, it might only have worked when accessing
 onion services as a client. Which would have been a terrible user
 experience.

 > It turns into administrative burden: if I am choosing to use Onions for
 greater integrity and disintermediation/NAT-punching, that the software
 inhibits me from accessing (say) Debian updates over Tor (unless I launch
 another daemon to overcome this handicap) seems bizarre.
 >
 > Surely it took more code to deny everyone this feature, than it would
 take to enable it?

 The code to deny the feature is ~10 lines of boilerplate. It's easily
 removed or made conditional.

 Replying to [comment:7 alecmuffett]:
 > tl;dr - you appear to be complaining about writing code that is
 necessary for this scenario to bypass code that has already been written
 on the presumption that my intention was/is "a bad thing" ?

 No, your intention is fine. It's completely understandable that you want
 to connect to other onion services or internet sites through the same tor
 instance you have running a single onion service. We just didn't discover
 this use case during the proposal process, or the  discussions on tor-dev
 about single onion service use cases. That's on me - I could have asked
 better questions, or asked more people.

 (We've prevented or warned against combinations like this in the past
 because they have anonymity implications, but that's not an issue here.)

 I have no issue with implementing this feature, I just want to design it
 so that it works (it must be multi-hop to access exits), and that it has
 an appropriate user interface (clearly documented torrc option(s)).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21284#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs