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

[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.  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).  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. 

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.)

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).

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. 

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).

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.

Cheers,

Rafal