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/27691reset bootstrap progress when enough things change2020-06-13T15:31:22ZTaylor Yureset bootstrap progress when enough things changeRight now, setting DisableNetwork=1 doesn't reset the bootstrap progress indicator. It probably should, because all network connections to bridges or relays will close. This will improve the user experience once we have #27103 in place...Right now, setting DisableNetwork=1 doesn't reset the bootstrap progress indicator. It probably should, because all network connections to bridges or relays will close. This will improve the user experience once we have #27103 in place, because then the earlier progress shown will be the initial network connection that everything else depends on.
We probably also want to reset the bootstrap progress when a configuration change causes us to disconnect from all our guards.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27308report bootstrap phase when we actually start, not just unblock something2020-06-13T15:30:07ZTaylor Yureport bootstrap phase when we actually start, not just unblock somethingRight now many bootstrap events get reported when the preceding task has completed. This makes it somewhat harder to tell what has gone wrong if bootstrap progress stalls.
[edit: The following isn't necessarily the best way to fix this...Right now many bootstrap events get reported when the preceding task has completed. This makes it somewhat harder to tell what has gone wrong if bootstrap progress stalls.
[edit: The following isn't necessarily the best way to fix this. It might be better to figure out how to report starting something when actually starting it.]
We should add completion milestones to bootstrap reporting. This makes bootstrap reporting more future-proof. If in the future we add a time-consuming task with (no bootstrap reporting) between two existing bootstrap tasks, it will be a little more obvious what's going on.
For example, say we have task X followed by task Z, but then we add a lengthy task Y without adding bootstrap reporting to it. In the old scheme without completion milestones, if Y stalls, the user sees:
* starting X
* starting Z
* [hang]
The user thinks Z has already started when no such thing has happened because Y is still in progress. If we add completion milestones, the user will see:
* starting X
* finished X
* starting Z
* finishing Z
in a normal bootstrap. If something gets stuck in task Y, the user will see:
* starting X
* finished X
* [hang]
This will make it more clear that something got stuck in between tasks.
In a one-line display like Tor Launcher, the completion milestones will normally flash by quickly and not be very visible to users. Completion milestones might make the NOTICE logs a bit more verbose.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27104report intermediate status when building application circuits2020-06-13T15:29:19ZTaylor Yureport intermediate status when building application circuitsDuring bootstrap, some minimum number of application circuits must be established before bootstrapping will complete. Right now, the user will receive no feedback of intermediate progress as a bootstrap circuit is being built. We shoul...During bootstrap, some minimum number of application circuits must be established before bootstrapping will complete. Right now, the user will receive no feedback of intermediate progress as a bootstrap circuit is being built. We should make this more granular, probably with intermediate progress at each EXTEND, to make visible when Tor is being slow to build circuits.Tor: unspecifiedhttps://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/25713"DisableNetwork is set" log message in Tor Browser scares/confuses users2020-06-13T15:24:08ZRoger Dingledine"DisableNetwork is set" log message in Tor Browser scares/confuses usersWhen Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-c...When Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-control network connections. Shutting down all existing
connections.
```
and if they're hunting for a log message that gives them a hint about why Tor doesn't work, that one is easy to find and seems really related to why their tor might not work.
So we have this recurring event where users come to us and say "My Tor Browser isn't working, it says DisableNetwork is set."
Now, Tor Browser legitimately starts Tor with DisableNetwork set, so Tor Browser will have time to ask the user whether they want to use bridges or proxies or etc before their Tor starts interacting with the network. So "well stop using that option then" is hopefully not our best plan.
But I wonder if there is a smarter way to have that phrased in the logs, so users have a better chance of guessing correctly what is going on.
(Long term we want to not send Tor Browser users to go read Tor's logs. But we're not there yet either.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24717Improve design of relay and bridge badges and map overlay2020-06-13T07:24:11ZirlImprove design of relay and bridge badges and map overlayThe code that draws the badges is at the end of the org.torproject.metrics.bot.BaseRelayImpl class:
https://gitweb.torproject.org/user/irl/metrics-bot.git/tree/src/main/java/org/torproject/metricsbot/tor/BaseRelayImpl.java#n297
For the...The code that draws the badges is at the end of the org.torproject.metrics.bot.BaseRelayImpl class:
https://gitweb.torproject.org/user/irl/metrics-bot.git/tree/src/main/java/org/torproject/metricsbot/tor/BaseRelayImpl.java#n297
For the redesign, mockups are all that's needed as I can do the actual Java code, but it might help to see how they are created. Essentially it builds up the image by drawing on to a canvas at fixed coordinates.
These badges are then converted into a bitmap image and uploaded for Twitter and Mastodon. The size of the badge is currently based on some "best practices" I found on a blog for Twitter, it works mostly in Mastodon too but I wonder if a change of size/aspect ratio would be useful.
In the future, I'd like to write JavaScript too that can build these as SVGs for dynamic inclusion in web pages so that relay/bridge operators can include them on their blog. These means that any dynamic text must be in a font we're allowed to embed.
There are currently 3 image types generated by metrics-bot:
Relay: https://twitter.com/TorAtlas/status/944267221769089024
Bridge: https://twitter.com/TorAtlas/status/944255643728441344
World Map: https://twitter.com/TorAtlas/status/944255648551849987
The world map image is mostly generated by xplanet (http://xplanet.sourceforge.net/) but there is an overlay bar at the bottom to add branding.
One idea that I have been thinking about is adding a "country" badge, which shows relay count, distinct AS count and advertised bandwidth alongside an image of the outline of the shape of that country, but I have no idea where I would get the country shapes from.irlirl