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

[Tor Bug Tracker & Wiki]

#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      |  Actual Points:
Parent ID:  #24689                     |         Points:
 Reviewer:                             |        Sponsor:  Sponsor4
---------------------------------------+------------------------------

Comment (by gk):

 Replying to [comment:44 mcs]:
 > Here is a fixup commit so you can see what we changed to fix the cancel
 problem:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug23136-03&id=1e8cd277bc8380f9ce169c2ce990cf580323d917
 >
 > And here is the entire revised patch:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug23136-04&id=d8ecbe221fbc691909cd4f070407901b531e6de8

 Thanks, works for me now. Here comes another round of feedback after some
 more testing:

 1) If I've been using meek just once in a session (could have been days or
 weeks ago I guess) and then try to request bridges I am getting the
 cryptic error mentioned in comment:40.

 2) Worse than 1): If I request bridges but then don't close the dialog but
 switch to use meek-{amazon,azure} havoc is breaking loose: my tor daemon
 is shut down, I get multiple error messages a la the one in comment:40 and
 after closing Tor Browser I need to manually kill meek-* processes.

 3) If I have bridges fetched I might want to change my mind and enter a
 custom bridge. However, I trigger one of the sanity checks for the bridge
 entry (Is it really an IP-address? etc.). Upon failure I want to go back
 and select the just fetched bridges. But now I am suddenly re-requesting
 them. I think the better behavior would be to only re-request them if I
 really had configured the custom bridge properly (like we do when
 selecting and *using* one of the default bridges). See 4) for a related
 but more general point.

 4) I noticed more than once while testing (to my surprise, even though
 that one was declining over time) that the moat radio button is behaving
 quite differently than the other two: It's immediately doing things, i.e.
 requesting bridges while the other two options are allowing you to select
 between different options or to enter own details. I can see why we did
 this in case the user has no bridges fetched yet and wants to have those.
 But still this option seems to run counter to the model we use for the
 whole remaining dialog: select an option and click "OK" so the thing the
 text of the radiobutton says gets done. Moreover, I fear that by
 accidentally selecting this option a user might leak network traffic they
 don't want to, let alone that we add unnecessary traffic/other costs for
 BridgeDB. So, at least after the user got some bridges (and even used
 them?) we could change that behavior? How about renaming the text to
 something like "Use a BridgeDB bridge" or something and then showing the
 available bridges with the "Request a New Bridge" when the option is
 selected? Sure, this would be one click more to get bridges from BridgeDB,
 at least for the first time, but I think given my points above I am
 inclined to say that's okay. (However, I might need a refresher on why we
 thought we should design it the way it is right now, if we did that.)

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