[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 mcs):

 Replying to [comment:49 gk]:
 > 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.

 Good catch. It seems that Kathy and I were so focused on the "first run"
 experience that we overlooked this scenario. The bad news is that I don't
 think it is easy to fix. The way meek is currently used inside Tor Browser
 does not allow for the possibility of two independent meek clients running
 at the same time (they want to share the meek-http-helper browser profile,
 which will not work). Kathy and I see a few ways to fix this:
 a) Use a separate browser profile for the meek browser when it is used for
 Moat (this requires a fix for #12716 and possibly other things inside
 meek-client-torbrowser).
 b) Give up on using the secondary browser and use meek-client to
 obfs4proxy's meek_lite mode for Moat. This has the downside that the TLS
 fingerprint will not match Firefox's when doing Moat).
 c) Modify Tor Launcher to kill the tor daemon before using Moat. But this
 might have undesirable side effects because some other part of the browser
 may be using the Tor network (e.g., for a file download). Also, while Tor
 Launcher knows how to restart tor if it is killed, it might be difficult
 to make sure we kill and restart tor in a robust fashion when we are in
 the middle of configuring settings.
 Kathy and I are currently in favor of pursuing a) but could be convinced
 to do something else.

 > 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.

 We are able to reproduce this now but have not determined the root cause
 yet. It may just be a race that occurs while the Moat processes are
 shutting down and the other meek ones are starting up, in which case the
 solution for 1) should also fix this problem.

 > 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.

 We included code to discard the BridgeDB bridges (obtained via Moat) if
 you click Connect and are not using them. But it would probably be more
 consistent to keep them around but not use them in the scenario you
 described; that way users can change their mind without much penalty.

 > 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?

 Since you think there is potential for confusion and some risk of a
 network leak, we should change the UI to require a second click.

 > 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.)

 I think the only reason it works how it does right now is that we were
 trying to stay faithful to Linda's design, which tried hard to reduce the
 number of clicks needed (by removing the wizard and generally streamlining
 things). But let's require the second click. Kathy and I have two
 questions though:
 a) What do you mean by "then showing the available bridges?" Do you mean
 offering a choice of bridge types (e.g., obfs3, obsf4) or do you mean
 showing bridges that the user has already obtained?
 b) What text should we use for the radio button label? Introducing
 "BridgeDB" without explaining it does not seem ideal, although the current
 design is somewhat cryptic as well. And it would be nice to keep the word
 "Request" because it avoids making the user think they need some knowledge
 ahead of time to use the middle radio button. Anyway, Kathy and I will see
 what we come up with for the label.

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