If you can imitate webrtc traffic why not to imitate torrenth traffic and make tor completely peer-to-peer without speed limitations. Domain fronting can be used for the connection to a “torrent-tracker” and relays (seeds) and leeches (clients) could exchange lists of relays and trackers.
1 Like
For most censors is problematic to block webrtc traffic as is widely used today for video conferencing. webrtc is encrypted by default, which makes hard for the censor to differenciate if you are doing a video conference or using snowflake. Also webrtc is an easy protocol to use as Pluggable Transport, as is transport where you can encapsulate your traffic easily on it.
But I will be surprised if censors have much problems blocking torrent traffic, and AFAIK many networks do block torrent or slow it’s speed. For the case where the censor does care of not blocking torrent totally it might not be able to make a Pluggable Transport that is not easy to distinguish from ‘normal torrent’ traffic. AFAIK torrent protocl is not encrypted and is oriented to transfer files, it will require ‘hacking’ the protcol into something else that what was designed.
5 Likes
I was video chatting in ICQ messenger recently, UDP seemed to be unencrypted, not DTLS (according to Wireshark 2.6).
Torrent traffic can be encrypted (TCP and UDP), but it doesn’t prevent some providers to limit the speed. They detect it anyway.
Even snowflake is very different from browser-based WebRTC.
Torrent traffic can be encrypted (TCP and UDP), but it doesn’t prevent some providers to limit the speed. They detect it anyway.
Writing comments doesnt look like a video conference anyway and the speed of snowflake is too low and unstable for a video conference. People need video chatting much less than torrents so I think providers will block webrtc and limit its speed.
And I agree that most people use messengers for video chatting not the unsafe browser in which every scriptkid can read your clipboard with passwords.