Browser-laptop: Decide which Tor process to use

[tomlowenthal]

If we ship a Tor binary (#12932) and are able to configure and run it as our own subprocess (#12934), what if we detect (#12931) an existing Tor process? How should we decide which process to use? Should we use our own process, but copy some of the user's existing torrc directives? Should we default to running our own, but provide an advanced configuration directive to allow a user to specify another Tor process to use? If we use a separate Tor process, should we take any measures to connect to its control port, or warn if it's not configured to the safe baseline that we'd expect?

[riastradh-brave]

The Firefox-based Tor Browser does two things:

1. Uses port 9150 by default for socks, and 9151 by default for control, in contrast to the usual defaults, 9050 and 9051, respectively.
2. On systems that support it, uses local sockets instead of tcp sockets for _both_ socks and control. (I didn't realize until today that the tor daemon even supported local sockets for socks.)

We should do both of these. The first is easy; the second will require teaching net/socket and net/proxy about local sockets for socks proxies.

[diracdeltas]

Agree that shipping our own Tor binary and using that exclusively seems like the safest route. Like Tor Browser, we can ship our own torrc file used by our Tor binary, and advanced users can edit that file if they want to.

[tomlowenthal]

Agreed: definitely just ship our own binary and use that always. I don't think we need to provide any advanced config options: if someone wants to edit Brave's torrc, they can do it directly. On systems which don't support local sockets, maybe we should randomize the TCP ports?

[riastradh-brave]

With tor's ControlPort auto configuration, the ControlPortWriteToFile /path/to/foo option causes tor to write the port number it has chosen for the _control_ port to /path/to/foo, which we could situate in the tor data directory under Brave's config directory. This is moot for Unix where we want to use a local socket anyway, but maybe it is useful for Windows.

For the _SOCKS_ port, there's also SocksPort auto, but there seems to be no option corresponding to ControlPortWriteToFile, which is a little puzzling because I'm not sure how you're supposed to get the port number in that case -- I'm not seeing an obvious way to get it out of the control channel. For the SOCKS port, until https://github.com/brave/muon/issues/469 is implemented, we _do_ need to use a TCP/IP socket for SOCKS. Will ask upstream about this.

[tomlowenthal]

I feel like we've decided which process to use — ours. What work are we currently tracking with this issue?

[riastradh-brave]

I was just using it as a dumping ground for notes, while on my mind but before they became actionable, on how to communicate with the tor process to minimize probability of interference with other possible tor processes on the system.

[tomlowenthal]

Okay, I'm going to close this one and if you want to use it to track IPC with Tor, feel free either to rename and reopen or create a fresh issue.