#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs