[tbb-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth                                           |
Parent ID:  #30000                               |         Points:  14-24
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by mcs):

 Replying to [comment:51 asn]:
 > mcs, it would be great to let us know whether we should proceed with the
 control port concepts given the concerns in comment:50. It would also be
 great to check the above tickets, and in particular #30382 to tell us
 whether the logic works tor browser, and what other info you need as part
 of the control port command to be able to tie it to a particular tab.

 Kathy and I think the logic described in #30382 will work for Tor Browser.
 I did ask one question in that ticket.

 That said, we have been thinking a lot about how to associate a control
 port event with a specific network request and/or a specific tab in the
 browser.  When Kathy and I were only considering the problem of how to
 show a prompt in response to a client auth failure, the limitations seemed
 acceptable.  We are less convinced that associating a control port event
 with a browser tab based on URL alone is a good idea if we are also going
 to use this same mechanism for address validation and improved error
 messages.

 We don't know the history of tor's use of SOCKS, but here is an idea:  We
 could add a tor option that allowed a client to include an request
 identifier within the SOCKS5 password field (we would need to agree on a
 delimiter since we would need `IsolateSOCKSAuth` to ignore the request
 identifier). Then, when tor generates a control port messages that is
 associated with a specific SOCKS request, it would include the request
 identifier.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:52>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online