Opened 12 months ago

Last modified 5 weeks ago

#23605 assigned defect

BOOTSTRAP PROGRESS=80 is a lie

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

Description

Tor can report BOOTSTRAP_STATUS_CONN_OR (PROGRESS=80, "Connecting to the Tor network") when it actually can do no such thing. In some situations (e.g., clock skew) this causes progress to get stuck at 80% indefinitely, resulting in very poor user experience.

Right now update_router_have_minimum_dir_info() reports the BOOTSTRAP_STATUS_CONN_OR event if there's a "reasonably live" consensus and enough descriptors downloaded. A client with a clock skewed several hours into the future can get stalled here indefinitely due to inability to select a guard: if the client's clock is skewed, it will never have a live consensus. (Guard selection seems to require a non-expired consensus, rather than a reasonably live consensus at least during bootstrap.)

We should either relax the guard selection consensus liveness requirement, or avoid reporting BOOTSTRAP_STATUS_CONN_OR when we have no reasonable chance of actually connecting to a guard for building application circuits.

Arguably we shouldn't start downloading descriptors until we have a non-expired consensus either, because that gets represented as a considerable chunk of the progress bar (40%->80%) in a way that could be misleading to a user. Making that change without additional work would cause bootstrap to get stuck at 40% instead of 80%, which might be an improvement. This can already happen if the client's clock is skewed several hours in the past.

Child Tickets

Change History (10)

comment:1 Changed 12 months ago by iry

Cc: iry added

comment:2 in reply to:  description Changed 12 months ago by arma

Replying to catalyst:

Arguably we shouldn't start downloading descriptors until we have a non-expired consensus either, because that gets represented as a considerable chunk of the progress bar (40%->80%) in a way that could be misleading to a user.

This is a really important thing to do, for the reason you describe but also for the even bigger reason that we're wasting bandwidth on fetching directory stuff that we will then probably not use -- which is an especially big deal on low-bandwidth clients. This is ticket #2878.

comment:3 Changed 12 months ago by catalyst

Sponsor: Sponsor8-can

comment:4 Changed 12 months ago by mcs

Cc: brade mcs added

comment:5 Changed 10 months ago by catalyst

Keywords: s8-errors added

comment:6 Changed 7 months ago by catalyst

Milestone: Tor: 0.3.3.x-finalTor: unspecified

comment:7 Changed 3 months ago by nickm

Keywords: 035-roadmap-subtask added
Milestone: Tor: unspecifiedTor: 0.3.5.x-final

comment:8 Changed 2 months ago by nickm

Keywords: 035-triaged-in-20180711 added

comment:9 Changed 6 weeks ago by catalyst

Keywords: s8-bootstrap added
Owner: set to catalyst
Sponsor: Sponsor8-canSponsor8
Status: newassigned

comment:10 Changed 5 weeks ago by intrigeri

Cc: intrigeri added
Note: See TracTickets for help on using tickets.