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.
> YouTube mainly throttles TOR
What I mean is, streaming media usually uses UDP (I don't know about YouTube, but I'd guess that's the case) and according to this thread, Tor routes only TCP and not UDP. So is YouTube and other streaming media being routed around Tor?
YouTube delivers video in chunks over the standard HTTPS port 443, as does Twitch. YouTube supports HTTP/3, so it will use UDP via QUIC if your browser and network also support it, but otherwise it will simply go over TCP.
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.
cargo install --git https://gitlab.torproject.org/tpo/core/oniux oniux@0.5.0
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
[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”?
Also you might want to read "Reflections on Trusting Trust" [2].
[2] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...