Search Mailing List Archives
[liberationtech] New report on Internet Censorship and Surveillance in Turkmenistan
jacob at appelbaum.net
Mon Jan 7 17:10:20 PST 2013
>>> What is the difference between Black Watch and ooniprobe,
>> 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
> 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
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
> 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,
More information about the liberationtech