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