Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

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

#23136: moat integration (fetch bridges for the user)
--------------------------------------------+------------------------------
 Reporter:  mcs                             |          Owner:  brade
     Type:  defect                          |         Status:  needs_review
 Priority:  Very High                       |      Milestone:
Component:  Applications/Tor Launcher       |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689                          |         Points:
 Reviewer:                                  |        Sponsor:  Sponsor4
--------------------------------------------+------------------------------

Comment (by antonela):

 Replying to [comment:64 brade]:
 > Replying to [comment:61 antonela]:
 > > Thanks @mcs for the explainer.
 > > So, in that case, my recommendation is to use a select
 >
 > Hi Antonela.  I think you misunderstand what we need your help with (and
 I apologize that you are coming in at the end of the process and working
 with someone else's design).
 >
 Yes.
 > We need help with the words that appear next to the radio button and the
 words that appear in the button (see image in comment:56).
 >
 > Linda's UX design and the implementation by Isis do not intend for the
 user to choose among the bridges returned from the BridgeDB server, so a
 select control would not be appropriate.  Each time the user requests
 bridges (see steps below) they receive a set of three and all three are
 used at the same time (the tor deamon figures out which one to use).
 >
 I see. Thanks a lot for sharing with me the technical background.
 > > About the captcha, will it show after the user selects which kind of
 bridge he wants?
 >
 > Here is the sequence of steps for displaying the captcha:
 > * user selects the radio button (currently labeled "Request a Bridge")
 > * user clicks the "Request a Bridge..." button
 > * [network activity occurs to obtain and display the captcha]
 > Here is what the captcha prompt looks like:
 https://trac.torproject.org/projects/tor/raw-attachment/ticket/23136/moat-
 Dec8-A-prompt.png
 >
 > The ASCII art in comment:59 happens after a correct solution for the
 captcha is submitted and a set of bridges is returned by the BridgeDB
 server.

 So basically, the flow is going to be as following

 [[Image(https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-1.png)]]
 [[Image(https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-2.png)]]

 > If all of the bridges from BridgeDB stop working, the user can "Request
 a New Bridge" to ask for a new set (which replaces the previous set).

 Honestly, I see the idea about to have double steps with a kind of
 rejection. But if this friction can improve the security, I'm in. IMO, the
 best label is the option A. Also, if at some point we want to offer a
 different source to get a bridge, it is easily extendible.

 I'm afraid that it could be converted into an infinite loop between not
 working bridges and request a new bridge button, which seems confusing.
 I'd like to review error user flows and see how they are working on with
 this iteration.

 Could we have a nightly build to reproduce locally? That could be useful
 :)

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