Show users a bandwidth graph or activity spinner during slow loads
I've been testing the Turbo Tunnel Quic Snowflake builds of Tor Browser, and every so often (anecdotally, 5-10% of the time) I end up with a snowflake that is super slow, like 5-10 kilobytes per second. So pages load but they take a minute or three.
This is probably pretty similar to the behavior that normal Tor Browser users get on low-bandwidth crappy internet connections around the world. So I bet I am not alone in this situation, and whatever fixes we develop here could benefit our next billion users.
I've been attaching a nyx to my Tor Browser (nyx -i 9151
plus patching my about:config snowflake bridge line for #33693 (moved) so the BW controller events will work) in order to watch nyx's bandwidth graphs. That way I know whether the browser is slowly loading its page, or just pretending that it's loading while actually no bytes are being transferred.
We should consider making a tiny bandwidth graph inside the Tor Browser interface, so normal users can discover whether their Tor is "working but slow" or "not working at all". I imagine a lot of users give up after the first minute of waiting for the page to load (bad for user retention), but also I've heard from folks in Kenya about waiting 30 minutes for a page to load before giving up (and if they had browser feedback that no bytes were coming through at all, they could do something else with that time).
It doesn't need to be a bandwidth graph. In fact maybe that's not the best plan, because I'd want to know the scale on the graph and then suddenly it can't be super tiny anymore. I think that I want to learn two things: how much bandwidth came through in the last second or so, and how much bandwidth came through 'pretty recently'. So I could imagine other visualizations, like a spinner that spins rapidly if I got bandwidth this past second, and spins slowly if I got bandwidth in the last ten seconds, and spins not at all if it's been longer than that.
From the Tor interaction side this is super easy: tor emits a BW controller event every second, with two numbers, one for 'in' bytes and the other for 'out' bytes. Tor Browser could listen for these events and then it would know the numbers.
Probably users trying to debug their situation will have situations where they want to know about both directions (and distinguish between them). For example, "my Tor Browser keeps sending requests but it never gets any responses" is a useful level of detail to be able to learn.
Two further thoughts in hopes they're useful: (a) modern Western browsers (designed for Americans on cablemodems) might not consider this problem, but maybe some other browsers for other types of users do encounter it and have come up with solutions? and (b) whatever we design for Tor Browser desktop might not be what we'll want for Tor Browser Android.