[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs