Re: [tor-bugs] #33035 [Applications/Tor Browser]: create strings for onion service error pages

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

#33035: create strings for onion service error pages
-------------------------------------------+-------------------------------
 Reporter:  brade                          |          Owner:  tbb-team
     Type:  defect                         |         Status:  new
 Priority:  Medium                         |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  ux-team, TorBrowserTeam202003  |  Actual Points:  0.25
Parent ID:  #19251                         |         Points:
 Reviewer:                                 |        Sponsor:
                                           |  Sponsor27-must
-------------------------------------------+-------------------------------

Comment (by sysrqb):

 Replying to [comment:25 mcs]:
 > Replying to [comment:17 antonela]:
 > > So, when we started to work on this task, we talked about to offer
 recovery paths for users who were experiencing the less happy user flow by
 getting any of these errors.
 > >
 > > Our main call to action here is `Try Again`. Can we verify if `Try
 Again` is the best recovery path for all these errors? Should any of those
 problems encourage another more successful path for recovery?
 >
 > Kathy and I did some thinking about this, and we do not think it makes
 sense to offer a `Try Again` button for 0xF6 (typo in .onion address).

 When we first started discussing this, we had the idea that we could
 *force* tor to bypass it's checksum verification and try connecting to the
 onion service regardless of checksum failure. This could be useful in the
 (off chance) there is a typo within the checksum (portion) of the address
 and not the public key portion. Overall, this has a pretty low probability
 of helping, because it is much more likely that the public key has a typo.
 Honestly, I don't have a strong opinion on this.

 On the one hand, I would like us to have usable/useful/smart "recovery"
 features. On the other hand, if the onion service is offline, then it is
 offline and we have absolutely no control over that. If the onion service
 address has a typo in the public key, then we don't have many recovery
 options. We could present a list of alternative (similar) valid onion
 addresses, but that is not something we can implement right now (it will
 take too much time, and I don't know how to create that list in a
 smart/efficient way).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33035#comment:27>
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