Display Socks 5 Proxy address and port to users

[Sammysupport]

Hello

please add in the GUI under Settings / Tor-Tab:

over the line, right side next to (after)

"Tor-Version: 0.4.." | Socks5 listener connection opened on 127.0.0.1: e.g. 60348

---

or just short: "Socks5-Port:"

(makes sense as there is space and users need not to fiddle it out of the small printed terminal text and mix it up with the controlport mentioned there)

Many Thanks.

[morganava]

@Sammysupport If you don't mind my asking, what is the use case for this? I presume you are wanting other applications to use Ricochet-Refresh's tor instance?

So, I don't necessarily think this is a good idea. Shared tor-daemon usage is not explicitly supported and I don't really want to encourage users to depend on Ricochet-Refresh for their 'tor' configuration, especially as in the grand scheme of things, the feature would be very short-lived as we're planning on switching to an Arti-based backend. I also don't want to give the illusion that this is a supported configuration, as the usage of a socks proxy on a particular port is an implementation detail.

I've run into similar situations in Tor Browser where users depend on implementation details for their own configurations, which then of course break when we improve things. Most recently, in Tor Browser for Android version 13.5 we switched to using a u nix-domain socket from the hard-coded localhost:9150 which of course broke some users. See this fourm post in the topic: https://forum.torproject.org/t/i-cant-use-tor-socks-proxy-at-port-9150-after-upgrading-to-version-13-5/13405

If you want to use tor for multiple apps, you should really use whatever is provided by your system's package manager! Ideally Ricochet-Refresh would follow the tor applications best practices document ( https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Tor_friendly_applications_best_practices#network-configuration ) with regard to using a system-wide tor daemon configured by environment variable. In version 4 this will be supported out of the box thanks to work in blueprint-freespeech/gosling#5

[Sammysupport]

Thank you for the feedback and the references.

The request has two reasons, first, I studied ricochet refreshed a bit and there is just space to display the important information, three items on the left side and only two on the right, so fill the missing position with one item. Indeed a use-case could be, e.g, to run an individual browser (e.g. not Firefox) over Tor, parallel to the messenger ricochet. So I want to browse and chat over one tor.exe and not open another tor.exe over Firefox.

(The idea to have a system tor deamon is nice and vidalia was such a tool (probably much too complicated and could be refreshed with a much simpler gui, which then works for any browser, also Firefox and also RicoChet. E.g. to make Vidalia portable with tor.exe and torrcf in one path). Another idea is to provide a library which is in the system or/and Api in each apllication, but that is another thing).

However the request was, just to show more transparency about important information (socks port and not control port) as there is space to show it.

(looking from the side of a Torbrowser user, your messenger running next to the Browser just needs also this port of Torbrowser, which is 9051 hardcoded, and could simplifiy the whole TorTab you provide? - if it is not a trust and security problem in the eyes for some users to base a messenger on the Tor Browser app - which for sure is secure. Just saying, you can de-attach the whole network starting tab and Api or Deamons, if the rule is: RicoChet works when Tor-Browser is launched and running - why all the work?).

Thanks for a consideration for the information in the gui about the socks port.

(as this port is in the terminal box also given, so it is just a question to summarize the terminal box about that info, which is: Tor is running, and Tor is running over this port, For users e.g. the info, which git-version of tor is running is not such important, so this also could be stripped off, as it is a focus of a developer to have the git commit number displayed?!).

[morganava]

So there are two points I think I want to make which are relevant to this discussion (sorry effort-post incoming).

The first is to sort of acknowledge how we (the tor application ecosystem) got here with regards to apps bundling tor and owning their own tor process, instead of relying on a system daemon or service. Most (if not all) stand-alone applications that I am aware of package and bundle their won tor daemon with their installer, and launch their own managed tor process.

The immediate problem is the practical one of packaging and dependencies, particularly on platforms which do not have a package manager. So, WIndows and macOS (ignoring apps installed through third-party package managers like homebrew or msys2 which can use the tor package of course). These platforms don't have a built-in way to say hey this app/package depends on this other app/package beyond runtime checks, which is a really shitty user-experience for developers to workaround. SO without platform support for automatically installing package dependencies, developers+packagers are forced to bundle all your dependencies together in your Windows installer or macOS dmg. Similar bundled dependencies solutions also exist for Linux of course with flatpak, appimage, etc.

The other problem, especially apps which deal with onion-services, is that our apps require the ability to specifically configure the tor daemon to suit a particular apps needs. The easiest and safest way to do this is of course by owning your own tor instance which you specifically configure for your app. If you want to have applications share a single tor instance, they may require conflicting configurations. For example, Ricohet-Refresh could require onion-service only traffic as an extra layer of defense, which is not going to be suitable for a web-browser user which wants to access clearnet domains or for a general 'make this app use tor' program like torify.

Another issue is that the tor daemon has no concept of permissions or rights with regards to which commands tor-controllers are allowed to execute. That is to say, if you have the control-port's password then you can connect and run ANY command on the running tor-daemon. On top of the potential here for apps accidentally misconfiguring each other, there is also a massive security/privacy issue here. Malicious tor-using apps could change other tor-apps configuration to minimise their security properties or outright break them.

There ARE solutions to this problem, but they are specifically engineered and specific. The Tails operating system team uses onion-grater between the tor-daemon and tor-using applications which acts as a layer of protection to make using a shared tor daemon safer.

The second point is that 'just put your app behind tor' is really not a general purpose solution for anonymity or security. This is the entire reason Tor Browser exists. There is a whole world of realities which exist in the browser space which makes using tor a necessary but insufficient part of browsing the internet anonymous. See the Tor Browser design doc for some light bedtime reading:

• https://gitlab.torproject.org/tpo/applications/wiki/-/blob/master/Design-Documents/Tor-Browser-Design-Doc.md?ref_type=heads

To be clear though, if your goal of hooking up your web-browser to tor is to just visit onion-services, and do not care about the anonymity, security, and privacy properties Tor Browser provides, then be my guest and go right ahead. You however ARE off in undefined-behaviour land and all of that entails :smile_cat:

Long-term, Ricochet-Refresh should support using a system-tor daemon, but only on platforms like Tails which are engineered to handle this added complexity safely and securely. We definitely do not want users to use applications (Ricochet-Refresh, Tor Browser, OnionShare, whatever) bundled tor daemon for general web traffic. They also should not be configured to use each other's tor daemon and control port for fear of stomping over each other's settings.

---

To answer your other question, the git number is displayed to help with bug reports if there was ever a problem with a particular tor daemon.

[Sammysupport]

A many thanks for the additional explanations.
Let's see together what the future will bring: in Linux, in Windows, in individual applications or Apis.

Both paradigms are valid, either to have everything integrated or to build on a base. Everything in one application is very convenient. I don't think there's anything wrong with a socket, as there was with Vidalia.

Or the current tendency in Linux to define a system-wide socket.

Vidalia for Windows in a portable version would be ideal, you have to see if it can still be compiled.

For a messenger, I think a separate socket in the gui or a tab that is available in an installer would not be wrong.

The idea that TorBrowser has more security aspects (to be listed) than Firefox or Opera via a Socket like Vidalia may be a separate exploration.

As Tor propagates HTTPS over webRTC (protocol sharing) it is to be questioned, if port sharing needs to be in a broader discussion? This would lead to a data retention rule or law to censor and surveil with ports. I am sure, that Tor might propagate freedom of the internet and also the freedom of its ports?!

[morganava]

ok