There’s a limited number of TCP ports available, and I personally believe new software should avoid choosing default ports and heavily discourage assumptions about what is running where.
In Tor’s case, I believe that ship has sailed: I’ve encountered a variety of software that attempts to detect whether Tor is active by checking 9050/tcp, Tor’s default SOCKS port. Tor’s use of this port has yet to be registered with IANA’s registry, but the port is nevertheless de facto associated with Tor.
In light of this, the Tor Project should take a moment to formally register that port with IANA. They may also consider registering port 9150/tcp: I think discussing this with IANA would be best.
To be clear, I still think it is a bad idea for software to equate Tor with an open localhost:9050/tcp port. Putting aside the rigidity this imposes, loopback addresses will always be inferior to Unix domain sockets, and default ports across machines will always be inferior to using SRV/SVCB records to advertise which port to use. Assigned ports are an inflexible crutch, best avoided. But when such a convention already exists, they are better than nothing.
Though I think it would be even better to eventually change Tor Browser’s default settings to avoid opening any TCP ports whatsoever: Unix domain sockets are a much better starting point.
I personally configure Tor to run as a launch daemon with a dedicated user. I open a SOCKS5 UDS accessible by basically everything, a control UDS with much stricter filesystem permissions, and a dormant timeout of 10 minutes. Configure Tor Browser to use those, and it works like a charm. I also open a SOCKS5 proxy at localhost:1080/tcp, as a concession to software incapable of using a Unix domain socket. I keep a list of the software in question: I’ll be removing that as soon as I can. ↩︎