17:00:37 #startmeeting OONI meeting 30-03-2015 17:00:37 Meeting started Mon Mar 30 17:00:37 2015 UTC. The chair is r2r0. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:51 oh wait 17:01:10 here in Italy it is already 19:00 17:01:14 the time the meeting used to occur 17:01:25 I am not sure if people are expecting it to start in 18:00 UTC 17:01:30 so in 1 hour 17:01:38 are people here? 17:02:02 (damn daylight savings, they may save some power, but they waste a bunch of human energy...) 17:02:16 * sbs is here 17:02:26 * sbs and is also saving a lot of daylight 17:02:41 * irl is here 17:03:07 * irl forgot how clocks work 17:04:20 also here 17:06:26 * anadahz is here 17:08:33 ok well it seems like we have overcome the time zone issue 17:09:00 I got a bit carried away in thinking of alternative clock and time parametrization formats 17:09:03 anyways 17:09:11 let's start 17:10:19 so this last week we mainly continued work on the Iran study of censorship circumvention tools 17:10:48 we have completed all the analysis of the tools and have implemented some of the tools 17:11:21 we should have copcompleted enough implementations and specs to be able to consider this milestone reached 17:11:45 though we should see if we can implement some more tests and write more specs tomorrow 17:13:10 a new release of ooni-probe is also now in pypi 17:13:27 1.3.0 and it includes the obfs4proxy test and unique report IDs 17:13:42 it will also record the address of the backend test helper used 17:14:04 aagbsn, anadahz: do you have something to add about the Iran CCT study? 17:14:55 yes, I have succeeded in getting Lantern to bootstrap cleanly using the feature/third-party-template you wrote 17:15:41 I found (and wrote a fix) for a bug that causes some restarting of Lantern due to how the timer works 17:15:58 perhaps we should talk about the types of tests we want to implement? 17:16:35 for now I just have a test for verifying that it bootstraps; by tomorrow I should have a test that can fetch content to determine if circumvention works 17:17:49 I found an annoying bug where my user's PATH doesn't seem to be respected - only absolute paths are working 17:19:12 anadahz: i have almost finished a test for the meek protocol, it's actually checking if the fronted request passes to the "inside" host. 17:20:32 great! 17:20:45 well I think that on the implementation side we are mostly good 17:20:52 what we should focus on is writing the specs 17:21:02 because the analysis is not the spec that should go inside ooni-spec 17:21:30 right; presumably each of the tools we test will dump its entire output in each test? or is that going to be too large a dataset? 17:21:44 for example the bridge reachability spec could be improved and it should also now contain information about obfs4 17:22:11 aagbsn: we should see 17:22:14 I think my reports are each 300KB 17:22:21 because of how much is spewed 17:22:22 I wouldn't worry about size that much 17:22:27 300k is fine 17:22:45 if you can filter some of it out it's perhaps ideal 17:22:56 mostly for usability by data consumers 17:23:13 well, I'd prefer to preserve the full output log 17:23:32 aagbsn: yes, but there should also be a summary of it 17:23:37 like only the key items of it 17:23:46 as a 'data consumer' I can say that more is better. 17:24:00 so that devs that want to do visualizations or analysis of it, then it may be more convenient for them to have a summary of it 17:24:13 that is ALSO a summary of it 17:26:03 well it should be documented what the output means then 17:26:10 or provide some example output in the test specification 17:27:02 I will anyways update the tool-list.md file with the division of tasks for specification and implementation 17:27:11 r2r0: do you have an example test spec of circumvention tool? 17:27:14 so that's it's more clear that they are two spearate activities 17:27:31 https://github.com/TheTorProject/ooni-spec/blob/master/test-specs/ts-011-bridge-reachability.md 17:27:34 is a good example 17:27:53 https://github.com/TheTorProject/ooni-spec/blob/master/test-specs/ts-000-example.md 17:28:02 this explains the test specification data format 17:28:42 * mrphs arrives and lurks 17:30:03 r2r0: do we know when we can publish these reports,specs,tests? 17:30:30 I think the specs are fine to publish as soon as we write them 17:30:36 and commit them to ooni-spec as PRs there 17:30:46 since they are actually part of OONI 17:30:55 without a specification you can't implement a OONI test 17:31:08 true 17:31:33 I think it's also fine to take portions of text from the analysis and put them in the spec 17:33:02 in other news I started adding support for an elastic search backend for the ooni-pipeline 17:33:05 https://github.com/TheTorProject/ooni-pipeline/commit/c20ad24e96736eb8dbebda6b23fe6ccde944b066#commitcomment-10450852 17:33:31 and robertkeizer highlighted it's strengths 17:33:56 from what he says elasticsearch may be more what we are looking for in a NoSQL DB, that is 1 insert and lots of reads 17:34:23 also this thing seems epic: https://www.elastic.co/products/kibana 17:35:41 Lunar^: any updates on the debian packaging stuff? 17:37:42 with anadahz we also had a call with the people of SecDev on possible areas of collaboration 17:37:56 in particular they will be submitting some of their test lists to the citizenlab test-lists repository 17:38:02 r2r0: sorry, got some side effects in the past days. I need to update to 1.3.0 and see how it goes 17:38:17 and we will see if there is a way to collaborate in some areas of software development 17:39:06 Lunar^: ah ok, let me know if there is something that needs to be fixed. I have tested it quite a bit and it seems much more stable. 17:39:54 the organisation of the hackfest is also progressing 17:40:29 and we seem to be quite set for the dates of 15-05-2015 to 17-05-2015 17:40:37 does that work for everyone here? 17:41:00 that's good for me 17:41:13 sbs: for me yes, I think we should reach out to Anna asap to see if that date is feasible 17:42:17 yes 17:42:26 sbs: can you send her an email about that? 17:42:40 r2r0: I think the document to be sent to Anna needs to explain at a higher level of abstraction why measuring censorship is relevant 17:42:47 r2r0: yes 17:43:04 r2r0: and also I think it would be great to have a little session at the beginning talking about this 17:43:24 yes ok I can add a context section 17:43:35 detailing why in general this field of work is relevant 17:44:12 r2r0: ok, I've tried to draft some text for this, I'll send it to you, it may help as a basis, maybe 17:44:45 ok good 17:45:00 it's maybe relevant to run and analyze some tests in Italy (local example) 17:45:08 yes true 17:45:23 I can compile all the IT blacklists 17:45:35 perfect 17:45:46 I will see if I can some good vantage points 17:45:55 we can setup a cronjob on the PWS machine 17:46:39 regarding the introductory session at the beginning, if you agree to do it, I can try to find someone at Nexa that has a policy background and can participate 17:48:13 I will also see if some italian groups can set it up to cover some ISPs 17:48:35 sbs: I am thinking that we should try to make it more of a hacking event and less of a talking one 17:49:26 if you look at the schedule in the document I shared with you, you will see that there is not much space for talks 17:49:37 r2r0: sure, 17:50:23 r2r0: and I have looked at the document, my point is that probably since they host the hackathon they also would like to know the implication of what we are doing 17:50:48 r2r0: at the EU hackathon for example there was a 20'-30' introduction before the hacking started 17:51:03 true 17:51:38 but I think it would be a pitty to have a policy person from nexa have to travel all the way to rome, just to give a 20 minute presentation 17:52:04 r2r0: yes, that's true, but we also have fellows who live in Rome 17:52:05 some of the implications can be briefly explained by us, but we should manage in 30 minutes to cover also the practical aspects of analysing the data 17:52:32 sbs: ah ok, well let's talk about this in the following days 17:52:41 r2r0: ok 17:53:23 other thing that we did this week was start writing the third party test template to support writing the CCT tests: https://github.com/TheTorProject/ooni-probe/pull/382 17:53:55 aagbsn gave me some feedback on it 17:54:21 regarding the resetting strategy for the timer 17:54:53 I suggested not resetting the timer, since it competes with OONI's built in timers 17:55:30 we might want to read the configured timers and raise an exception if they conflict (if the built-in timers are less than the 3rdparty template) 17:55:47 ah that was not clear to me previously 17:56:01 we actually are already supposed to be handling this case 17:56:15 kudrom implemented it some time ago 17:56:48 my diff is just def outReceived(self, data): 17:56:48 - self.resetTimer() 17:57:17 otherwise chatty applications keep resetting the timer until OONI's hard limit comes along 17:57:37 I proposed launching the 3rdparty apps in setUp instead of the test_ methods 17:58:00 so that you can have a test class that launches an application, runs various tests, and then everything exits at shutdown 17:58:32 https://github.com/TheTorProject/ooni-probe/commit/e9dfc89 17:58:33 here it is 17:58:58 this needs to be investigated properly 17:59:09 because it needs to be handled properly 17:59:25 I will add this part of the chat to the PR 17:59:46 well, that case isn't handled 17:59:54 because the timer gets reset whenever more output appears 18:00:09 yes I see what you mean 18:00:25 it will reset only the local timer, but not the measurement timeout one 18:00:35 they should both share the same timer 18:00:36 ah, that is an interesting idea 18:00:52 well, timeout is a failure case usually 18:01:11 yes, but in some cases it's part of the test 18:01:15 for example tor, never exits 18:01:28 so you can't use the exit status to determine if it fails 18:01:31 you need to use time 18:01:32 that's why I think that if you need long lived processes, it shouldn't be launched as a measurement 18:01:56 and you know it has failed, because you get nothing on stdout for a certain amount of time 18:02:40 ah, I thought that the fail/success would be determined by - scraping messages from output that indidcate success from the application, or successfully using the application to fetch a resource 18:03:19 yes, in some cases you can do that 18:03:26 but in others you need to depend on a timeout 18:03:45 * isabela raises her hand for a quick note (don't want to disrupt the discussion tho) 18:03:51 as in the tor case, where it will stall if it can't connect to any directory authority 18:04:09 aagbsn: let's continue discussing this on the PR on github 18:04:14 isabela: yes, please 18:04:57 yes, then we reach the timeout case, or the first test as a bootstrap check can fail and timeout (by not seeing a successful bootstrap), or failing a simple 'does it work' check 18:05:21 r2r0: thanks / I wanted to thank for updating the status for march and just remind if you guys can review your plans for april and let me know if there is anything blocking you or you depend on for april 18:05:30 (that's it) 18:08:55 isabela: ok, we will update it as needed, currently I don't think there is anything blocking on anything in the roadmap for april 18:10:02 does anybody have anything else to talk about or discuss before we finish this? 18:11:15 r2r0: have you got the stickers? 18:11:52 *ooni stickers 18:12:06 anadahz: not yet, they had some problems with the files I gave them, but they should both be in print 18:12:29 I also received a package, but was not at home and didn't have time to pick it up yet 18:12:36 it could be one of the stickers 18:12:53 I will probably discover this on the 4th of April as I am now in Milan 18:15:54 if there is nothing more to be said I would say we adjourn 18:16:01 thanks for attending 18:16:20 right on 18:17:21 #endmeeting