17:00:37 <r2r0> #startmeeting OONI meeting 30-03-2015
17:00:37 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:51 <r2r0> oh wait
17:01:10 <r2r0> here in Italy it is already 19:00
17:01:14 <r2r0> the time the meeting used to occur
17:01:25 <r2r0> I am not sure if people are expecting it to start in 18:00 UTC
17:01:30 <r2r0> so in 1 hour
17:01:38 <r2r0> are people here?
17:02:02 <r2r0> (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 <aagbsn> also here
17:06:26 * anadahz is here
17:08:33 <r2r0> ok well it seems like we have overcome the time zone issue
17:09:00 <r2r0> I got a bit carried away in thinking of alternative clock and time parametrization formats
17:09:03 <r2r0> anyways
17:09:11 <r2r0> let's start
17:10:19 <r2r0> so this last week we mainly continued work on the Iran study of censorship circumvention tools
17:10:48 <r2r0> we have completed all the analysis of the tools and have implemented some of the tools
17:11:21 <r2r0> we should have copcompleted enough implementations and specs to be able to consider this milestone reached
17:11:45 <r2r0> though we should see if we can implement some more tests and write more specs tomorrow
17:13:10 <r2r0> a new release of ooni-probe is also now in pypi
17:13:27 <r2r0> 1.3.0 and it includes the obfs4proxy test and unique report IDs
17:13:42 <r2r0> it will also record the address of the backend test helper used
17:14:04 <r2r0> aagbsn, anadahz: do you have something to add about the Iran CCT study?
17:14:55 <aagbsn> yes, I have succeeded in getting Lantern to bootstrap cleanly using the feature/third-party-template you wrote
17:15:41 <aagbsn> I found (and wrote a fix) for a bug that causes some restarting of Lantern due to how the timer works
17:15:58 <aagbsn> perhaps we should talk about the types of tests we want to implement?
17:16:35 <aagbsn> 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 <aagbsn> 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> 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 <r2r0> great!
17:20:45 <r2r0> well I think that on the implementation side we are mostly good
17:20:52 <r2r0> what we should focus on is writing the specs
17:21:02 <r2r0> because the analysis is not the spec that should go inside ooni-spec
17:21:30 <aagbsn> 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 <r2r0> for example the bridge reachability spec could be improved and it should also now contain information about obfs4
17:22:11 <r2r0> aagbsn: we should see
17:22:14 <aagbsn> I think my reports are each 300KB
17:22:21 <aagbsn> because of how much is spewed
17:22:22 <r2r0> I wouldn't worry about size that much
17:22:27 <r2r0> 300k is fine
17:22:45 <r2r0> if you can filter some of it out it's perhaps ideal
17:22:56 <r2r0> mostly for usability by data consumers
17:23:13 <aagbsn> well, I'd prefer to preserve the full output log
17:23:32 <r2r0> aagbsn: yes, but there should also be a summary of it
17:23:37 <r2r0> like only the key items of it
17:23:46 <flargleblarf> as a 'data consumer' I can say that more is better.
17:24:00 <r2r0> 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 <r2r0> that is ALSO a summary of it
17:26:03 <r2r0> well it should be documented what the output means then
17:26:10 <r2r0> or provide some example output in the test specification
17:27:02 <r2r0> I will anyways update the tool-list.md file with the division of tasks for specification and implementation
17:27:11 <anadahz> r2r0: do you have an example test spec of circumvention tool?
17:27:14 <r2r0> so that's it's more clear that they are two spearate activities
17:27:31 <r2r0> https://github.com/TheTorProject/ooni-spec/blob/master/test-specs/ts-011-bridge-reachability.md
17:27:34 <r2r0> is a good example
17:27:53 <r2r0> https://github.com/TheTorProject/ooni-spec/blob/master/test-specs/ts-000-example.md
17:28:02 <r2r0> this explains the test specification data format
17:28:42 * mrphs arrives and lurks
17:30:03 <anadahz> r2r0: do we know when we can publish these reports,specs,tests?
17:30:30 <r2r0> I think the specs are fine to publish as soon as we write them
17:30:36 <r2r0> and commit them to ooni-spec as PRs there
17:30:46 <r2r0> since they are actually part of OONI
17:30:55 <r2r0> without a specification you can't implement a OONI test
17:31:08 <anadahz> true
17:31:33 <r2r0> I think it's also fine to take portions of text from the analysis and put them in the spec
17:33:02 <r2r0> in other news I started adding support for an elastic search backend for the ooni-pipeline
17:33:05 <r2r0> https://github.com/TheTorProject/ooni-pipeline/commit/c20ad24e96736eb8dbebda6b23fe6ccde944b066#commitcomment-10450852
17:33:31 <r2r0> and robertkeizer highlighted it's strengths
17:33:56 <r2r0> 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 <r2r0> also this thing seems epic: https://www.elastic.co/products/kibana
17:35:41 <r2r0> Lunar^: any updates on the debian packaging stuff?
17:37:42 <r2r0> with anadahz we also had a call with the people of SecDev on possible areas of collaboration
17:37:56 <r2r0> in particular they will be submitting some of their test lists to the citizenlab test-lists repository
17:38:02 <Lunar^> 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 <r2r0> and we will see if there is a way to collaborate in some areas of software development
17:39:06 <r2r0> 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 <r2r0> the organisation of the hackfest is also progressing
17:40:29 <r2r0> and we seem to be quite set for the dates of 15-05-2015 to 17-05-2015
17:40:37 <r2r0> does that work for everyone here?
17:41:00 <anadahz> that's good for me
17:41:13 <sbs> sbs: for me yes, I think we should reach out to Anna asap to see if that date is feasible
17:42:17 <r2r0> yes
17:42:26 <r2r0> sbs: can you send her an email about that?
17:42:40 <sbs> 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 <sbs> r2r0: yes
17:43:04 <sbs> r2r0: and also I think it would be great to have a little session at the beginning talking about this
17:43:24 <r2r0> yes ok I can add a context section
17:43:35 <r2r0> detailing why in general this field of work is relevant
17:44:12 <sbs> 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 <r2r0> ok good
17:45:00 <anadahz> it's maybe relevant to run and analyze some tests in Italy (local example)
17:45:08 <r2r0> yes true
17:45:23 <anadahz> I can compile all the IT blacklists
17:45:35 <r2r0> perfect
17:45:46 <r2r0> I will see if I can some good vantage points
17:45:55 <r2r0> we can setup a cronjob on the PWS machine
17:46:39 <sbs> 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 <r2r0> I will also see if some italian groups can set it up to cover some ISPs
17:48:35 <r2r0> 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 <r2r0> 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 <sbs> r2r0: sure,
17:50:23 <sbs> 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 <sbs> r2r0: at the EU hackathon for example there was a 20'-30' introduction before the hacking started
17:51:03 <r2r0> true
17:51:38 <r2r0> 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 <sbs> r2r0: yes, that's true, but we also have fellows who live in Rome
17:52:05 <r2r0> 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 <r2r0> sbs: ah ok, well let's talk about this in the following days
17:52:41 <sbs> r2r0: ok
17:53:23 <r2r0> 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 <r2r0> aagbsn gave me some feedback on it
17:54:21 <r2r0> regarding the resetting strategy for the timer
17:54:53 <aagbsn> I suggested not resetting the timer, since it competes with OONI's built in timers
17:55:30 <aagbsn> 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 <r2r0> ah that was not clear to me previously
17:56:01 <r2r0> we actually are already supposed to be handling this case
17:56:15 <r2r0> kudrom implemented it some time ago
17:56:48 <aagbsn> my diff is just      def outReceived(self, data):
17:56:48 <aagbsn> -        self.resetTimer()
17:57:17 <aagbsn> otherwise chatty applications keep resetting the timer until OONI's hard limit comes along
17:57:37 <aagbsn> I proposed launching the 3rdparty apps in setUp instead of the test_ methods
17:58:00 <aagbsn> so that you can have a test class that launches an application, runs various tests, and then everything exits at shutdown
17:58:32 <r2r0> https://github.com/TheTorProject/ooni-probe/commit/e9dfc89
17:58:33 <r2r0> here it is
17:58:58 <r2r0> this needs to be investigated properly
17:59:09 <r2r0> because it needs to be handled properly
17:59:25 <r2r0> I will add this part of the chat to the PR
17:59:46 <aagbsn> well, that case isn't handled
17:59:54 <aagbsn> because the timer gets reset whenever more output appears
18:00:09 <r2r0> yes I see what you mean
18:00:25 <r2r0> it will reset only the local timer, but not the measurement timeout one
18:00:35 <r2r0> they should both share the same timer
18:00:36 <aagbsn> ah, that is an interesting idea
18:00:52 <aagbsn> well, timeout is a failure case usually
18:01:11 <r2r0> yes, but in some cases it's part of the test
18:01:15 <r2r0> for example tor, never exits
18:01:28 <r2r0> so you can't use the exit status to determine if it fails
18:01:31 <r2r0> you need to use time
18:01:32 <aagbsn> that's why I think that if you need long lived processes, it shouldn't be launched as a measurement
18:01:56 <r2r0> and you know it has failed, because you get nothing on stdout for a certain amount of time
18:02:40 <aagbsn> 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 <r2r0> yes, in some cases you can do that
18:03:26 <r2r0> 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 <r2r0> as in the tor case, where it will stall if it can't connect to any directory authority
18:04:09 <r2r0> aagbsn: let's continue discussing this on the PR on github
18:04:14 <r2r0> isabela: yes, please
18:04:57 <aagbsn> 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 <isabela> 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 <isabela> (that's it)
18:08:55 <r2r0> 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 <r2r0> does anybody have anything else to talk about or discuss before we finish this?
18:11:15 <anadahz> r2r0: have you got the stickers?
18:11:52 <anadahz> *ooni stickers
18:12:06 <r2r0> anadahz: not yet, they had some problems with the files I gave them, but they should both be in print
18:12:29 <r2r0> I also received a package, but was not at home and didn't have time to pick it up yet
18:12:36 <r2r0> it could be one of the stickers
18:12:53 <r2r0> I will probably discover this on the 4th of April as I am now in Milan
18:15:54 <r2r0> if there is nothing more to be said I would say we adjourn
18:16:01 <r2r0> thanks for attending
18:16:20 <aagbsn> right on
18:17:21 <r2r0> #endmeeting