[tor-dev] Brainstorming a Tor censorship analysis tool

[George Kadianakis]

Philipp Winter <identity.function at gmail.com> writes:

> Hi there,
>
> Deliverable 6 for sponsor Z says:
>
>> 6. Start a tool that a censored developer can run to discover why their Tor is
>> failing to connect: brainstorm a list of "things to check", and sort them by
>> how useful they'd be to check / how hard they'd be to build. (#7137)
>
> The deliverable is due on Feb. 28, 2013 so we should get started.
>
> Some background about the deliverable:
> The reason for this project is that debugging possible censorship events is
> tedious right now. We often have no access to machines in censoring countries
> and we are dependent on users creating packet dumps for us. This tool should
> speed up and automate this process to some extent. Censored users should run it
> and the tool should then collect data which should then somehow reach us.
>
> I created the following wiki page which should contain all the necessary
> information:
> https://censorshipwiki.torproject.org/TorCensorshipAnalyzer
>
> Please add/modify stuff and share your opinion. Since there is quite some
> overlap with OONI, it would be great if the OONI people could give feedback.
>

One thing I consider important in such a tool is unit and integration
testing. Ideally, it should be possible to run unit tests on all of
its features, to test whether they would work in a real environment
and whether any of them are trivially broken.

Unfortunately, designing and writing such unit tests is not easy since
you have to emulate a censored network. While developing daphne, me
and Arturo considered doing that by using iptables or by
monkey-patching the networking methods of Python/Twisted with methods
that censor outgoing traffic. Both of those ideas wouldn't fully
emulate a censored network, but if developed correctly they would give
you an idea of whether a test will work in Real Life or not.

I'm mentioning this because I noticed that you don't have testability
included in your feature list, and that might bite you in the
long-term. Either because you will have to spend lots of unscheduled
time writing tests, or because you won't have the time to write any
tests (and your features will break frequently, like in OONI).