[tor-dev] Brainstorming a Tor censorship analysis tool
identity.function at gmail.com
Wed Dec 26 21:52:20 UTC 2012
First of all thanks a lot for summing all of that up in such great detail,
Arturo. Comments inline.
On Fri, Dec 21, 2012 at 04:16:32PM +0100, Arturo Filastò wrote:
> # Collection of packet captures specific to the sent and received packets
> When you run a ooniprobe test that inherits from the scapy test template
> the packets sent and received (i.e. that are answers to the packet(s) sent)
> will be captured.
> When configured to not include the probe IP address, source IP of sent packets
> and dst IP of received packets is replaced with 127.0.0.1. (warning: if the IP
> address of the probe is present in some other parts of the packet it will not get
> stripped, for example if it's present in the ICMP citation)
Sounds like a good thing to have.
> # Reporting system
> Currently we only support collection of YAML formatted reports (that means not
> .pcap files) and only via Tor Hidden Services.
> Extending it to support reporting via HTTP(s) should be trivial and is a feature
> that we have already received a request for.
> Adding support for collecting also .pcaps also probably does not require that much
> amount of time and is something that will happen in the near future.
That sounds good. Hidden services will not be useful in this case because Tor is
expected to be unavailable but HTTPS could work.
> # Things to come
> ooniprobe will soon expose a HTTP based API that binds to localhost that can then
> be (optionally) exposed as a Tor Hidden Service. Such API will allow researchers to
> connect to a probe and run some tests and will allow us to build a JS/HTML5 client
> interface to allow users to select which tests to run and monitor the status of running
Hmm, what's the use case here? To provide an "anonymous" ooniprobe which can be
controlled remotely by people I trust? I guess it won't be possible to hide the
probe's IP address since I can just run a test which makes it connect to an IP
address under my control?
> More details here:
> For a birds-eye view of the project see:
Thanks. On a more general note, a core requirements is to make the analysis tool
easy to use since we can't expect users to mess around with configuration. How
easy do you think would it be to package an ooniprobe with our analysis tests in
a self-contained executable which can then simply be run by users?
> Even if you do not end up using ooniprobe for developing your system today, I
> highly encourage you to use the libraries that we are using so that in the
> future we can find a way to integrate code from each others projects.
More information about the tor-dev