Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:31:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/27103report initial OR_CONN as the earliest bootstrap phases2020-06-13T15:31:22ZTaylor Yureport initial OR_CONN as the earliest bootstrap phasesWe 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...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.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/27102gather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATU...2020-06-13T15:29:17ZTaylor Yugather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATUS enum valuesIf we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (#25502), there aren't many numbers remaining to insert between some existing phases (if we ...If we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (#25502), there aren't many numbers remaining to insert between some existing phases (if we stick to integers).
We should decouple these so we don't have to cram everything into a tiny portion of the progress bar. It also doesn't make sense to report progress phases that we will never need to execute.
Alternatively, renumber the enums to give us more space toward the beginning of the progress bar.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22266gather info on jump-to-80% issues2020-06-13T17:43:43ZTaylor Yugather info on jump-to-80% issuesThis ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the ...This ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the logs and the control connection jumps from 0% to 80% almost immediately. This is misleading and causes user frustration, as reported by Linda's study.
When bootstrapping with existing directory information, we should rescale the progress numbers so they advance on something resembling a linear time scale, which is probably closer to what users expect to see.Tor: 0.4.0.x-finalTaylor YuTaylor Yu