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 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
