[liberationtech] New report on Internet Censorship and Surveillance in Turkmenistan

[Jacob Appelbaum]

Rafal Rohozinski:
> Jacob:
> 
>>> What is the difference between Black Watch and ooniprobe,
>>> practically?
>> 
>> Or rephrased, we'd be happy to take patches for ooniprobe if the 
>> features aren't already implemented and if nothing else, we'd like
>> to ensure that our output data formats are compatible for
>> analysis.
> 
> There may be 50 ways to leave your lover, but  generally about a
> dozen proven ways to measure censorship and surveillance :-)  From
> that  point of view, no, there are no significant practical
> differences between how Black Watch and ooniprobe test and detect
> censorship/surveillance events. 

That seems odd. We're trying to create a general taxonomy with
OONI/ooniprobe/other tools. We have general tests for specific details
(eg: DNS packet contains a lie, first hop terminates TCP connections,
etc) and from that, we are able to say interesting things about the
network in question.

>  As you know, I've been involved with
> ONI for the past decade, and I know you've taken a very keen interest
> in these issues in the last few years (by you,  I also mean the TOR
> project). 

Well, I've tried for the better part of ten years to learn about the
internal methods of ONI.

> Consequently,  I think that at a technical level of our
> thinking is quite strongly aligned  around a clear understanding of
> the challenges involved. In that respect, there is strong synergy
> between Black Watch and ooniprobe and I hope that we can align both
> projects in 2013. I'd include here participating in the ooniprobe
> project  at the coding  and conceptual level.  At a minimum,   we are
> committed to making sure that the output  format/data for both
> systems is the same.

Ok. Sounds interesting. Our output format is rather straight forward and
documented here:

  http://ooni.readthedocs.org/en/latest/

> 
> Consequently, the main differences between the two projects  may be
> in the considerations driving  the design and usage model.
> 
> Black Watch was designed to provide recurrent 24X7  testing against
> specific resources.  Initially, this was driven by  the difficulty we
> faced at ONI  in testing for just-in-time filtering, or filtering
> around elections and other temporally-bound events.  This meant fewer
> targets for testing,  but a more rapid, recurrent  and re-targetable
> testing cycle.  Unlike rTurtle (the ONI testing tool) it was not
> built for  broad spectrum testing/detection for all blocked/filtered
> content  (although it  is capable of that as well.)

ooniprobe has tests designed to be run constantly or to be run when
interested in answering specific questions.

> 
> We wanted Black Watch to be responsive - to give the tester immediate
> feedback and to make the data quickly accessible and easily
> understandable.  We spent a lot of time developing GUI's so as to
> make the process of tasking multiple testing devices and  correlating
> data intuitive. Currently the system allows users  to schedule
> testing, and group testing by country, region, service.  In fact, we
> spent a lot of time on the visualization aspects overall so  as to be
> able to  show real-time patterns across country/services ( sort of
> like a  weather forecast).
> 

We're not focused on analysis of data across the entire network of
probes as we want to create a pipeline. We do plan a GUI for a given
tester and currently our tools are console tools with instant feedback.

> Sustainability was also a core part of the Black Watch design
> criteria.    The "sustainability" motivation  is pretty
> straightforward  and based on my experience with Psiphon  where an
>> open source project is sustained through  commercial contracts that
> make the service available to those living in countries practice
> political censorship of the Internet.   In the case of Black Watch,
> it's the same: use  commercial contracts to off-set the cost of
> creating publicly available Open Data on censorship and surveillance.
> What kind of contracts are we talking about? Mostly "due diligence":
> Companies, service providers, broadcasters pay content delivery
> providers for services that they often cannot verify.  Black Watch
> can  provide that verification.

This generally fits with an open taxonomy of terms,
verifiable/reproducible data, and free/open source software tools.

> 
> We also spent a lot of tome thinking about obfuscation and resilience
> so as to  limit detectability and  communication with remote testing
> devices (not an easy challenge, as you can surmise).
> 

We covered a bit of this in our paper at FOCI last year. rTurtle had a
rather serious problem in this department - how do you solve this problem?

> At some stage in the near future we will share a design document so
> as to lay this out as clearly as possible.  Contrary to popular
> belief, SecDev is not a massive behemoth, rather we are a relatively
> small shop with lots of activities so time/brain cycles available for
> working on this is the biggest constraint.
> 

I'd love to see these documents just openly published, especially if
you're already collecting data in the wild.

All the best,
Jacob