Circuit Display in Tor Browser being Refactored Upstream

Development
2

If you have references to the plan of modifications/enhancements they plan to make, I’d like to see. I don’t know JavaScript so my input is limited to the desired behavior, but I know enough to understand why the Circuit Display was hidden.

  1. Current state: We fake the reply with onion-grater and TBB doesn’t like it, so it hides. The TBB behaviour of hiding is better than throwing an error, but I believe a short error message would be better because then it would be a handled error instead.

  2. A cleaner way was described above on item 1, but what we considered before, I wrote it here:

For the Tor Circuit View to appear, it requires valid credentials replied from the SENTCONNECT eventarchive.org and if they are not the same credentials the Tor Browser sent by that tab, the circuits will not be shownarchive.org. Tor Browser wants to get the same SOCKS_USERNAME and SOCKS_PASSWORD it send for that tab in the first place, if it doesn,t the whole tab is not shown, you can check the reply with the Browser Console (Ctrl+Shift+J): Torbutton NOTE: no SOCKS credentials found for current document.
The interest is not showing the circuits per se, but at least showing literally Hop1, Hop2 and Hop2 to not confuse users why the tab is not shown. Another side effect is that it also hides the button New circuit for this site, but still available in the supermenu, but less convenient and not expected by the user to be this way.
If someone with JavaScript knowledge could patch upstream, at least showing the New circuit for this site even if the credentials don’t match would be a start, but it currently is not shown because either the Tor Button shows completely or doesn’t show at all. A more difficult task would be to instead of not showing the circuit view, if the browser fails to get the correct credentials, it could show a helpful text that it can’t show the circuits because it could not determine the stream. There is a lower chance of rewriting the countries and IPs of the circuits to fake data if it can’t establish the link because upstream could consider this a workaround. Anyway, a better user experience is expected from the Tor Circuit View, even if an error message, so at least it is understood by non-developers or for people not familiarized with the Tor Button and Tor Browser source code.

  1. To my knowledge, Whonix and Tails do the same thing, via onion-grater. I don’t think linking to the profiles will help because the profiles need to adapt depending on the use case and what TBB sends. TBB profile: Tails and Whonix.

  2. The only spurious warnings I know is to the “Browser Console”: Torbutton NOTE: no SOCKS credentials found for current document. Gateway doesn’t know if the client only is using TBB or is using many other tor applications, therefore the choice of hiding every circuit request was made. This probably doesn’t happen in Tails because they use onion-grater’s option restrict-stream-events and the client address is on a different network namespace but still in the same machine, so they don’t need to worry about circuit leaking to other applications as they are restricted by TBB netns. The desired response from TBB from my point of view is to hide the circuit when it can’t get the desired information and not log to an user facing dialog that it couldn’t get the information. What is:

  • OK: Errors in the Browser Console.
  • NOT desirable: Errors at the Circuit Display, this could cause more confusion to the user. Maybe a warning message in place of the Circuit Display would be better so the error is handled instead of handled by hiding.

Summary: We don’t hide the circuit view directly by modifying TBB, it is a consequence of tor-circuit-display.js not liking the almost blank response it received from onion-grater. A desired behaviour in my point of view would be to handle the error with maybe an error message.

1 Like