[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Flash proxy deployment
Perhaps, the flash proxy concept could also be used for bridge reachability
scanning [1].
Web sites could embed JavaScript code which tries to establish a connection to a
provided bridge. The result (reachable or not) is then sent back. When users
from different censoring countries visit one of these web sites, they scan the
given bridge and report whether it is reachable or not from their vantage point.
That way, we could get a more detailed idea of which bridges are blocked and
where. This would open the gates for reputation-based bridge distribution
strategies [3].
Naturally, there are problems:
- How do we give the bridges to be scanned to the web site visitors without
making it easy to enumerate them?
- Bridges are not just blocked on the IP layer but also on the TCP layer or
during the SSL handshake. Flash/WebSockets lack the flexibility to do
fine-grained scanning across protocol layers. Maybe this problem could be
solved by the web server impersonating proposal [2].
- Web site visitors need to get the script as well as the bridges to scan from
somewhere. This "somewhere" can be blocked. In order to avoid that, the script
could be hosted on a large provider which the censor is unwilling to block.
- Making web site visitors scan bridges without their knowledge or informed
consent is problematic.
I don't have a lot of faith in this idea but I figured it would be worth posting
it here.
[1] https://blog.torproject.org/blog/research-problem-five-ways-test-bridge-reachability
[2] https://lists.torproject.org/pipermail/tor-dev/2012-June/003673.html
[3] http://freehaven.net/anonbib/#proximax11
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev