Huh. I had a conversation with a Tor developer on this topic about a decade ago, when network namespaces were still kind of a new hotness - the feedback I got was that it would be an easy way for people to think they were being secure while still leaking a bunch of identifiable information, so I didn't push that any further.
I think the tor folks made a fundamental strategic error by pushing that line. Yes, people who face a serious threat need to use tor browser and still pay attention to other ways to leak etc. But if we'd got 'tor everywhere' it would still make mass surveillance a lot harder. For one thing, today mass surveillance can detect who is using tor. If everyone was using it that wouldn't matter.
When you have torsocks or torify for everything, you're gonna leave your footprint through tor, whereas something like Tor Browser is designed specifically not to leave any print on the web.
Using tor directly on the kernel level means that your DNS is gonna leak. Your OS telemetry is gonna leak etc.
It's still a good idea but it should be implemented top to bottom and nothing left in between, otherwise you're de-anonymized quickly.
> This project is an attempt to implement a simple user-space network stack that
can handle TCP *and UDP* state such that it is possible to forward the traffic
into the Tor network.
DNS is already done by Tor. In fact, if you feed it a raw IP, it will warn in tor's output that it received an IP, which may indicate that the user has accidentally setup browsing via Tor, but DNS resolution via a normal, unsecured way.
YouTube mainly throttles TOR hard and it's a bit of a fight uphill against a never ending avalanche of Captchas or a straight up service refusal. Bridges solve this, by going through exit nodes that are not publicly listed to be TOR exist nodes. Even with bridges it's still a high chance to trip Google's bot detection.
Thank you, therefore my first impression seems right: without any provision for UDP this isn't an easy-to-setup and transparent way for any user to preserve his/her privacy.
As always this will depend on your definition for "any user".
Users who try to do a lot of UDP traffic will have to change their habits, yes. But a majority of users who don't know a lot about computers rarely do anything on a PC that isn't driven by the browser anyway.
But at least the users who try to use UDP won't wind up specifically leaking info, just wind up slightly confused why certain things aren't working.
Hmm. I assumed this worked like torsocks in that it would direct traffic through the locally running tor daemon. However, I've noticed that if I stop the locally running tor daemon, oniux still works whilst torify and torsocks do not. [edit] The documentation does actually say this. Pretty neat.
It works inside docker as well, but I needed to use --privileged. Just copied the binary into a debian:12 container and it works there:
docker run -it --rm --privileged -v "$PWD/oniux:/usr/bin/oniux" debian:12
Oniux seems like an "officially" supported tool similar to orjail (which hasn't received a commit in four years, but still works great as a shell script with iptables/iproute tools [1]). Orjail has also an option to run with firejail for further isolation, which seems to be still a feature that Oniux doesn't have.
Fun fact, this has been broken with curl for 5 years (and so are the blog examples), because Tor developers previously insisted that apps shouldn't attempt to resolve .onion domain names: https://daniel.haxx.se/blog/2025/05/16/leeks-and-leaks/
I don't think anonimity is a concern for people who still use Chrome at this point.
It does allow accessing onion sites, though, even though anyone running an onion site will probably tell you that it's a terrible idea to use plain Chrome to access them.
No. First of all, just check for `navigator.brave`. If it exists, it's Brave. When I ran a .onion site I added a JavaScript check and if navigator.brave was present, it redirected users to a specific page saying:
> Hey, there's something funny about your Tor Browser. When browsing Tor hidden services (.onion), you should be using Tor Browser. Are you using an outdated version, or perhaps something else entirely?
Brave is chrome. Tor browser is firefox, has a bunch of tweaks, different default settings, and a different fingerprint. Also when browsing on Tor, you should disable JavaScript as it's a source of many vulnerabilities.
The main strategy is that most people on Tor are using Tor Browser. This creates a cluster big enough to blend in. If you're using anything else, you're sticking out.
You always could by just setting the proxy environment variables (or in settings). The standard port for the tor daemon is 9050.
In fact, it's relatively easy to write a socks proxy that lets you route traffic through a arbitrary protocols. For example, I can serve/visit websites on syncthing with a socks5 proxy as a translation layer: https://github.com/acheong08/syndicate
They use hexchat as an example but do these processes run with the users configuration? Wouldn't this leak IRC usernames if you forget to change it.
... Or leak cookies if you launch a browser?
Separation of concerns - although Tor goes to great lengths to prevent fingerprinting, Tor and Oniux’s main aim IMHO is to make the source IP untraceable.
Same thing could have been said about using Tor to login to Gmail (if it were not HTTPS).
What do you mean by leak usernames? It would leaks that a username uses tor. It would still leak that all of the usernames connecting to the same IRC host would be the same person.
IRC seems pretty dangerous if you want to remaining anonymous considering how many people are logging disconnection times allowing them to be correlated with other network disruption events.
Tor is anonymizing you primarily from the network. There are many use cases where you do want to be authenticated/known to whoever you are talking to. You just want observers to not know.
In your example of correlation of connection times, it may not be your goal to remain anonymous from the network and its participants, you may be interested in the location-hiding properties, and/or adversarial networks (like local government or corporate networks) and firewalls.
Irssi iirc used to default your username to your system username, so noobs would leak their given name by accident. After seeing that I changed my username in Linux to always be the most common username
I was talking more about you using HexChat with your preferred username "FooBar", but then when on Tor you want to be "SpamEggs". If you launch HexChat through oniux and it reads your config file, you might hit the login button before changing your name from FooBar to SpamEggs.
Using tor directly on the kernel level means that your DNS is gonna leak. Your OS telemetry is gonna leak etc.
It's still a good idea but it should be implemented top to bottom and nothing left in between, otherwise you're de-anonymized quickly.
> This project is an attempt to implement a simple user-space network stack that can handle TCP *and UDP* state such that it is possible to forward the traffic into the Tor network.
YouTube mainly throttles TOR hard and it's a bit of a fight uphill against a never ending avalanche of Captchas or a straight up service refusal. Bridges solve this, by going through exit nodes that are not publicly listed to be TOR exist nodes. Even with bridges it's still a high chance to trip Google's bot detection.
HTTP/3 is unsupported.
Maybe I'm wrong, but it seems similar to I2P where if you want "UDP", you'd need bespoke plugins/transports/whatever for each application.
Users who try to do a lot of UDP traffic will have to change their habits, yes. But a majority of users who don't know a lot about computers rarely do anything on a PC that isn't driven by the browser anyway.
But at least the users who try to use UDP won't wind up specifically leaking info, just wind up slightly confused why certain things aren't working.
[0]: https://www.whonix.org/wiki/Tunnel_UDP_over_Tor
It works inside docker as well, but I needed to use --privileged. Just copied the binary into a debian:12 container and it works there:
https://tpo.pages.torproject.net/core/arti/
[1] https://github.com/orjail/orjail/blob/master/usr/sbin/orjail
https://raw.githubusercontent.com/orjail/orjail/master/usr/s...
I hope they can find a resolution.
It does allow accessing onion sites, though, even though anyone running an onion site will probably tell you that it's a terrible idea to use plain Chrome to access them.
> Hey, there's something funny about your Tor Browser. When browsing Tor hidden services (.onion), you should be using Tor Browser. Are you using an outdated version, or perhaps something else entirely?
Brave is chrome. Tor browser is firefox, has a bunch of tweaks, different default settings, and a different fingerprint. Also when browsing on Tor, you should disable JavaScript as it's a source of many vulnerabilities.
In fact, it's relatively easy to write a socks proxy that lets you route traffic through a arbitrary protocols. For example, I can serve/visit websites on syncthing with a socks5 proxy as a translation layer: https://github.com/acheong08/syndicate
Same thing could have been said about using Tor to login to Gmail (if it were not HTTPS).
IRC seems pretty dangerous if you want to remaining anonymous considering how many people are logging disconnection times allowing them to be correlated with other network disruption events.
In your example of correlation of connection times, it may not be your goal to remain anonymous from the network and its participants, you may be interested in the location-hiding properties, and/or adversarial networks (like local government or corporate networks) and firewalls.
Is there a “common name”?