Have a separate backend for the tor circuits
After working on #41600 (closed), gTorCircuitPanel
is:
- listening out for new circuit events,
- gathering the node data associated with the circuit,
- storing this information.
This should really move to some dedicated backend, which also controls requesting new circuits, or other tor circuit related operations.
We would also want it to track information about what bridge is in use, as part of this. Right now gConnectionPane
in "about:preferences" is having to do a similar but separate approach to gTorCircuitPanel
to determine whether a bridge is in use, and which one.
Besides separating concerns, it could also address some problems we have currently:
- We gather circuit node data but we never free it, or know when it is safe to free it. This is because the tor process itself does not store the circuit data after it has already expired, but in the browser we still need that information to tell the user what circuit was used to show the current page. We might be able to address this by integrating the circuit node information with the firefox request process by storing it within some relevant object, so it only sticks around for as long as it is in use. I don't know much about the firefox process, but maybe something like the page's
loadInfo
? - We don't have a clean way to determine whether the current page is establishing the initial circuit, or requesting a new circuit, or will never get a circuit (like a
data:
uri). We do some guess-work to get around this, but it also means we cannot implement designs like !587 (comment 2888415) or !587 (comment 2892297). Again, if we had an integrated backend, it could track the exact state. -
gTorCircuitPanel
is not shared between windows. As a result, a web page split across two windows can be missing information if the other window hasn't picked up the circuit event. E.g. if you open a web page in a new tab and open the same page in a new window, then the new window will be missing the circuit display. -
gConnectionPane
currently only collects circuit data while "about:preferences" is loaded. So it will not know which bridge is in use until it receives a circuit event.