Opened 8 days ago

Last modified 2 days ago

#27103 assigned defect

report initial OR_CONN as the earliest boostrap phases

Reported by: catalyst Owned by: catalyst
Priority: Medium Milestone: Tor: 0.3.5.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: usability, ux, ux-team, bootstrap, 035-roadmap-subtask, 035-triaged-in-20180711, s8-bootstrap
Cc: brade, mcs, linda, isabela, iry Actual Points:
Parent ID: #22266 Points:
Reviewer: Sponsor: Sponsor8


We should always make the earliest bootstrap phases be our first connection to any OR, regardless of whether we already have enough directory info to start building circuits.

When starting to boostrap with existing directory info, there might not be a need to make an initial connection to a bridge or fallback directory server to download directory info. This means that the initial OR_CONN to a bridge or guard displays on a progress bar as 80%, when in fact a fairly "early" dependency (the initial connection to any OR) could be failing.

Intuitively, starting Tor Browser and seeing the progress bar hang at 80% for a very long time is frustrating and misleading. A user who sees the progress bar hang at at 5% or 10% has a much better idea of what's going on.

Existing directory info can be reflected in the progress bar as a rapid jump after the initial OR_CONN succeeds. This seems less likely to frustrate users.

Child Tickets

#27167newtrack "first" OR_CONNCore Tor/Tor
#27169newmonitor bootstrap directory info progress separatelyCore Tor/Tor

Change History (2)

comment:1 Changed 8 days ago by catalyst

Keywords: s8-bootstrap added
Sponsor: Sponsor8

comment:2 Changed 2 days ago by catalyst

I think we need at least two subtasks:

  • Make a new abstraction to track OR_CONNs and notice whether they're the first connection to any relay since "reset", whatever that means. Maybe DisableNetwork=1 should reset this "first connection" status.
  • Refactor directory info progress into a separate abstraction, instead of calling control_event_bootstrap() directly. This will let us defer reporting of "enough directory info" until we have successfully connected to at least one relay or bridge.
Note: See TracTickets for help on using tickets.