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 (https://ooni.torproject.org/docs/api/ooni.templates.html#module-ooni.templat...) 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 tests.
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: https://ooni.torproject.org/docs/architecture.html#ooniprobe-api
For a birds-eye view of the project see: https://ooni.torproject.org/docs/architecture.html
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.
Yes, agreed.
Cheers, Philipp