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