I’m not sure if this is of any use for our design, but there is a new feature being added that may be useful for security. Maybe this is only useful if the software is is running on the same host as the Tor client, like TAILS?
The easy answer is:
Yes. SocksSocket would make leaks less likely.
The more sophisticated answer is:
could improve Whonix anonymity a bit as well. But this is really just a minor thing.
In Whonix, leaks would get forced through Tor’s TransPort, unless transparent proxying has been disabled. Not a big problem. Still, for even better stream isolation (Stream Isolation), it would be good to keep Tor’s TransPort clean from misc, unexpected traffic.
This is such a minor thing, it is questionable if the extra implementation effort would be worth going that route.
We would have to create unix socket files and configure them to connect to a Whonix-Gateway SocksPort. If this is possible.
I’ve got a different concern. They might make some changes in future such as using this feature by default in Tor Browser. While not having systems in mind, where Tor runs on a different system than the client application (for example Tor Browser). I hope they won’t make some day some changes, which make it impossible to use Whonix’s design. We already have a similar problem with onionshare, see:
Then they need to know about this to stop them from going into a direction that endangers this project’s survival.
For now, they’re just adding a new feature to Tor. There is no immediate danger yet. Since lots of time has been invested into the Tor SocksSocket feature, it’s very unlikely they just trash it.
The danger starts when they start configuring TBB to use SocksSockets and forget about compatibility with users who wish to use normal SocksPorts. When they consider this, it’s time to mention compatibility. If we’re lucky, there is bigger demand and it will stay compatible. If not, we may be lucky to find someone who fixes this / writes compatibility code. Or we find some other workaround such as forwarding SocksSockets to the gateway.
This should not sound like a complaint… In my experience, in past they were not much concerned about compatibility with Tor running on separate systems. That’s also why CPFP (onion-grater, a Tor Control Port Filter Proxy - filtering dangerous Tor Control Port commands - Design Documentation - Whonix) has been written to keep up with their changes. One has to be very diplomatic. And keep the human part, their feelings in mind. I guess the “Whonix’s concept won’t work then anymore” isn’t an argument that is going to convince them. Whonix is still a minority way to use Tor, so they have their priorities. It’s best to suggest approaches, when having advantages for non-Whonix users in mind, such as Tails and other users. If the Whonix advantage is just a by product, chances are best. This should not sound like a complaint… They also implemented stuff, that helps Whonix a lot such as the TOR_SKIP_LAUNCH environment variable (Implement a Tor controller as a browser extension (#6009) · Issues · Legacy / Trac · GitLab), which I am very thankful for.
For now there is no reason to say something, but to watch what’s happening. Please trust me on that one. You can see my previous diplomatic and technical way to discuss thing here:
Without applauding myself, I guess I am doing quite well. I mean, the worst thing now would be to panic and freak out saying something like “You’re endangering Whonix’s surivial with this. Stop now!”
Nice work, I’ll leave these topics to you then.
I am not saying it should be left to me. I am happy for pointing me at relevant tickets I may not have noticed.
This was just my summation for not freaking out, being diplomatic.
I was talking about the diplomacy part. Its obvious that you know how to handle it well