Isn't all this reserved to TCP, in other words in which way may it protect non-TCP activity?
> 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.