| Hi all, Whilst working on a project the thought crossed my mind that it would be useful to me (the exact reasons as to why aren't relevant here) for a web browser to be able to run a Tor client entirely in the browser, that is using a wasm build of Arti or my own Torrosion library. Obviously, a browser can't just go start making random outbound TCP connections, for good reasons. But what a browser can do is make outbound WebRTC and WebSocket connections, which brought me to Snowflake. At least in most situations, I would have no need for the whole WebRTC infrastructure of Snowflake, as the browser is not *usually* restricted from making a WebSocket connection. So, naturally I looked at the Snowflake source code to see how one would implement that, to discover some things I'm a little confused by. Firstly, the Tor node that the broker hands out seems to be a) hard coded and b) just the one (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/broker.go?ref_type=heads#L75). Secondly, the number of active relays offering WebSocket connections are a grand total of 4 (https://metrics.torproject.org/rs.html#search/transport:snowflake?fields=transports). Therefore, my question to those more knowledgeable is: why is this situation considered acceptable? Why is such relay centralisation fine? Is it even fine? Mit freundlichen Grüßen, Q Misell (sie/ihr - she/her) 🌲 Please consider the environment before using AI to process this email. -- Max-Planck Institut für Informatik Fon +49 681 9325 3547 Forschungsgruppe Internet Architecture (INET) Campus E1.4 514, 66123 Saarbrücken |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ tor-project mailing list -- tor-project@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-project-leave@xxxxxxxxxxxxxxxxxxxx