monero in Whonix with torsocks for better stream isolation

Maybe I wasn’t clear enough. I’ll try one last time. If this is annoying, please ignore it. However, please read at least the last section. Thanks.

These things are Whonix-specific:

  1. The documentation lists Monero in the SocksPort table but does not specify a port number. Please designate a port for Monero. I cannot fully contribute my work to Whonix without a declared port because otherwise, it would be at risk of breaking in the future. All I ask is that you choose a four-digit number and publish it in the documentation.

  2. I am fairly confident that my systemd unit file would be a significant improvement for Monero to include in the documentation, especially since it is tailor-made for Whonix. I don’t know what else to do but provide it to you. It is well tested.

These are minor, but also Whonix-specific:

  1. Besides the discussion of Monero in the context of Whonix, this note states that the documentation includes a blanket statement about isolation flags that requires further explanation. This is a Whonix-specific question.
  1. Perhaps this is better suited for the QubesOS forum, but it should also be possible to answer here, especially since the documentation mentions the qubesdb-read/qubes-gateway command.
  1. The Whonix documentation includes Monero. Of course, because what could be more relevant to a Tor anonymity system than anonymous currency? I hoped to start a discussion about the tweaks I made to adapt Monero to Whonix. I understand that Whonix strives to be a great baseline platform for Tor. But if not Monero, then which application should be the first-class citizen?

:heart: :heart: :heart:

Overall, I know that open-source work can be quite taxing. Please know that I have your best interests, as well as those of the Whonix project, at heart. Please don’t take the following section negatively. Consider it constructive criticism.

Also, note that I am not trying to take advantage of your time by asking for free support. On the contrary, I spend a lot of time making useful improvements to Monero within the Whonix setting that enhance the project. I understand that if you are busy with other things, it’s impossible to handle this correctly, and you have every right to prioritize accordingly. However, linking to documentation that I’ve already read does not benefit the project. It may even prevent future contributions. In fact, I had planned to make some improvements outside of Monero.

I initially had one simple question about optimal Monero privacy. When I didn’t receive a satisfactory answer, I figured it out myself, tested it, and then came back to contribute. What more could an open-source project want? All I wanted was final validation from a Whonix developer on the questions I’m only 99% sure about. Not being able to incubate people like me isn’t good for the project. My recommendations are as follows:

  1. Simplify the project and refocus on important aspects if you don’t have time to maintain critical applications, such as Monero. This could include the baseline Tor VM architecture or just a few applications.

  2. Hire someone who can maintain the documentation better and perform community work.
    It’s laughable that there are documents about running an onion-based Mumble server and outdated messaging services, yet Monero doesn’t receive the necessary attention. This doesn’t bode well for the project.

:heart: :heart: :heart:

This is not something that users should do. It’s a task for developers.

Fortunately, no IETF style approach required. The “designated port number” style is outdated. [1]

If you must, you can use any of these for a choice that is non-controversial from a Tor network load perspective.

That doesn’t answer what is the right choice form the perspective of Monero developers. [1]

I cannot confidently talk about settings such as --proxy= and --tx-proxy=. Specifically not under time pressure.

Also not about other settings not limited to --prune-blockchain, --sync-pruned-blocks. In my position, it’s best not to comment on it and refer to upstream.

The thing which I guess you are referring to is this:

Based on a linked tor-talk discussion from 2012.

If you are seeking guidance which stream isolation flags are suitable/acceptable, you cannot get this from me.

  • Tor network health impact: Responsible for this answer would be The Tor Project.
  • Monero specific network impact: Responsible for this answer would be The Monero Project.

It seems wrong for me to comment on this any further other than existing upstream Tor Project guidance.


[1] So what is the right approach if manual SocksPort number selection, Stream Isolation flags configuration is not something users should deal with? It’s not a task for Whonix / Monero / Tor users. It’s a task for Monero / Tor Project developers.

“Do it like Tor Browser. Do it like OnionShare.”

The two relevant websites are [A] and [B]:

[A] Tor friendly applications best practices

This is a task for Monero upstream.

Settings such as --proxy= and --tx-proxy= should come with reasonable defaults. These could point to “localhost”, even in case of Whonix. [2] This is not something users should need to tinker with. These should be options for advanced users only.

Tor friendly applications best practices by The Tor Project guide is minimal.

This project is archived. Its data is read-only.

It was migrated from Tor project trac. I don’t have the edit history handy. It would probably only be available on the web archive. Upstream Tor Project doesn’t provide great guidance on this. Application developers such as Monero developers realistically can only look “how other applications are doing it” and try to emulate that.

[B] Whonix friendly applications best practices

The way to go for upstream applications such as Tor Browser, OnionShare at the time of writing for:

  • outgoing traffic is to use IsolateSOCKSAuth, and
  • incoming traffic is to use Tor onions created through Tor control protocol.

And now maybe for Monero is not the best time to deeply integrate with these C-Tor features. Tor Arti (Tor rewrite written in Rust) may have a very different interface.

So in short, the way to make progress it for Monero developers and/or Tor Project developers show interest in this topic and engage in a conversation. They’re welcome to ping me, and I am happy to share my knowledge and opinions.

Documentation is good enough as is. Detail enhancements to perfect Tor integration / stream isolation are up to Monero / Tor Project.

The skills required are not readily available on the job market. It’s a complex threat model, there is no education curriculum and it’s not a straight-forward task at all. Related:

Wiki pages are based on contributions depending on contributor interest. The VoIP wiki page first edit is 2018. Monero wiki page 2020.

See also:
User Expectations - What Documentation Is and What It Is Not


[2] Thanks to:

anon-ws-disable-stacked-tor redirects connections on Whonix-Workstation localhost to Whonix-Gateway. IsolateSOCKSAuth remains intact.

1 Like

Thank you very much!

I got it. I will move to the Monero/Tor communities, and if I am successful, I will contribute back here.

I have one final question. Based on what you said, I understand that Whonix correctly redirects localhost to the Whonix gateway. Is that correct? If so, then I wouldn’t need to run qubesdb-read/qubes-gateway, and the systemd file would be compatible with plain systems running Tor, non-Qubes-Whonix, and Qubes-Whonix. Is that correct?

I disagree with your stance on the documentation. As time passes, you should consider removing or archiving outdated pages. They have no value and actually degrade the quality of the documents. I don’t want to know how things worked in 2018; I only care about the present.

1 Like

Yes. And it’s best if applications are Tor friendly (which will lead to these using IsolateSOCKSAuth).

I do archive pages when outdated / unmaintanable.

Or deprecate.