Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#28329: Design TBA+Orbot configuration UI/UX
-------------------------------------------------+-------------------------
 Reporter:  sysrqb                               |          Owner:  tbb-
                                                 |  team
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3,         |  Actual Points:
  TorBrowserTeam201903, tbb-8.5                  |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by sysrqb):

 Replying to [comment:50 gk]:
 > Replying to [comment:47 sysrqb]:
 > > anto, gk, thanks for the reviews! I believe I corrected all of the
 comments. Anto, do you have an opinion on how we should handle GeKo's
 comments in comment:46? I haven't tried this new branch with Gk's patch
 for #28802
 >
 > One thing I noticed both with your older and newest branch for this bug
 is that it seems Tor is happily bootstrapping for a while before switching
 to bridges. I have not looked deeper if that's actually an issue but it
 makes me suspicious to see, with your older branch, Bootstrapped 5% and
 10% messages before getting the warnings that e.g. some obfs3 bridges are
 not reachable and then bootstrapping continues with Bootstrapped 15% and
 20% messages before I see notices that new bridge descriptors got fetched
 (for those two bridges that _are_ actually working).

 I noticed soemthing similar on rare occasions, too. I have trouble
 reproducing it, though. It seems related to the background TorService
 stopping Tor. Maybe there is a race condition where the user presses the
 connect button in tor browser, tor browser begins the bootstrapping
 process and sends the "start tor" signal to TorService, TorService starts
 the Tor process and waits for the control port. If the user presses the
 settings icon before TorService successful opens a controller connection,
 then the "stop tor" signal is ignored.

 This seems a little different than the bug you described because Tor
 shouldn't begin bootstrapping without bridges and then suddenly switch to
 using a bridge. However, I haven't tested this branch with working bridges
 yet, so maybe these bugs are related. I'll try reproducing this bug today.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28329#comment:53>
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