Well that's perfect. So what I'll do is redirect efforts from the onionoo reimplementation using metric-lib reimplementation to this problem. It sounds like an entertaining diversion. All the components are the same, instead it just recognizes particular events like censorship. And since now there's nothing and all.... Getting the requirements drafted sounds like it will take awhile anyway. --leeroy On 8/16/2015 at 7:09 AM, "Karsten Loesing" wrote:[Moving this thread back to the list.] On 16/08/15 12:50, l.m wrote:
So how does one actually fix it. All I've read here is that there may be a new version, and thanks for anyone who makes an effort. Who makes an effort? How to make an effort. It should be obvious why the list should stay. It makes censorship visible which then makes analysis easier.
If you're not going to provide method that people can contribute to a fix you might as well get rid of it then.
I could imagine two scenarios here: - Somebody writes a better censorship detector on their own which produces fewer false positives than the one we currently have [0], and at some point we start running that on a Tor host and possibly have it send notifications to this list. - The Tor Measurement Team sketches out requirements and possibly a design for a future censorship detector and finds somebody to work on it with the goal to run it on a Tor host and possibly send notifications to this list. The planning part here may take another four to six weeks [1], and it's yet uncertain whether this project will be higher priority than all the other things that need doing. Karsten [0] https://research.torproject.org/techreports/detector-2011-09-09.pdf [1] https://people.torproject.org/~karsten/volatile/measurement-roadmap.pdf