Test Tor

emdee 2022-10-28 22:44:44 +00:00
parent 8b31d77071
commit 01b183d7a7
2 changed files with 7 additions and 6 deletions

@ -136,3 +136,4 @@ Details:
* https://community.torproject.org/onion-services/setup/
* https://community.torproject.org/onion-services/
* https://www.wired.com/story/tor-browser-russia-blocks/
* https://nusenu.medium.com/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac

@ -15,14 +15,14 @@ traffic look like another protocol like HTTP or whatever:
So the best way to handle this may be to improve the documentation in
Tox clients of how to use Tor. Whether or not you trust Tor
(you can't trust exit nodes 40% of the time) it is the only thing
that works right now in e.g. Egypt or Iran. And people can test the Tor
setup with their brower (or TorBrowser) to make sure they are working
before they try Tox over Tor.
(you [can't trust exit nodes >25% of the time](https://nusenu.medium.com/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac))
it is the only thing that works right now in e.g. Egypt or Iran.
And people can test the Tor setup with their brower (or TorBrowser)
to make sure they are working before they try Tox over Tor.
The only way of getting a lot of resilience "cheaply" is to encourage
bootstrap node operators to also run a Tor client to serve the node
over Onionv3. This is the only way I can see dealing with the fact
bootstrap node operators to also run a Tor client to serve the node
over Onionv3. This is the only way I can see dealing with the fact
that Tox is a network of so few bootstrap nodes. If the Tox nodebase was
improved to serve BS nodes, and OnionV3 relays, it would be much more
resilient. I'm assuming the adversaries cannot block .onion addresses