[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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 gk):

 Replying to [comment:53 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.

 I actually think that's a general Tor issue as I see it on desktop as well
 (I guess I could have tested that earlier :( ):
 {{{
 Mar 13 14:11:38.000 [notice] Bootstrapped 5%: Connecting to directory
 server
 Mar 13 14:11:38.000 [notice] Bootstrapped 10%: Finishing handshake with
 directory server
 Mar 13 14:11:38.000 [warn] Proxy Client: unable to connect to
 2001:470:b381:bfff:216:3eff:fe23:d6c3:443 ("general SOCKS server failure")
 Mar 13 14:11:38.000 [notice] Bootstrapped 15%: Establishing an encrypted
 directory connection
 Mar 13 14:11:38.000 [notice] Bootstrapped 20%: Asking for networkstatus
 consensus
 Mar 13 14:11:38.000 [notice] new bridge descriptor 'ndnop3' (fresh):
 $8DFCD8FB3285E855F5A55EDDA35696C743ABFC4E~ndnop3 at 109.105.109.165
 }}}
 That's weird, though...

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