17:00:04 #startmeeting 2016-05-02 OONI weekly dev gathering 17:00:04 Meeting started Mon May 2 17:00:04 2016 UTC. The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:07 here we go 17:00:15 greetings 17:00:34 * willscott waves 17:00:54 #info 17:01:00 here 17:01:11 here 17:01:21 here 17:01:32 #info venezuela study/report 17:01:38 hi 17:02:41 excellent so let's try to keep today's report backs nice and tight. Since some of you have already circulated them it should just be a trivial copy paste job. 17:04:12 What I did last week (2016-04-25) 17:04:13 ========================== 17:04:13 * Work on making a new release for ooniprobe and oonibackend 17:04:13 * Work on debugging deployment of oonibackend on MLAB 17:04:13 What I plan to do this week (2016-05-02) 17:04:14 =============================== 17:04:17 * Review the SSL cert validation branch based on feedback from Simone 17:04:20 * Review the PR of Lorenzo on measurement-kit-ios 17:04:22 * Work on the web_connectivity test branch 17:05:50 ...(timeout?) nothing new here; no new work on the https backend endpoint, but feel free to bug me about it. EOF 17:06:10 I'm in the process of getting satellite in shape for usenix ATC. I expect that will transition into coordinating with anadahz on getting those reports into unified storage with ooni. EOF 17:06:59 # What I did last week (2016-04-25) 17:06:59 1. MK: merge Antonio Langiu PRs (GeoIP, LibreSSL, build system) 17:06:59 2. MK-android: help Lorenzo with updating the JNI repository and with 17:06:59 rolling out the first version of the Android app 17:06:59 3. MK: review Arturo's PR on SSL certificates validation 17:07:02 4. MK: finish now-working NDT prototype 17:07:04 # What I plan to do this week (2016-05-02) 17:07:07 1. MK: continue review of Arturo's PR on SSL certificates validation and 17:07:10 possibly review other PRs 17:07:12 2. MK: move NDT prototype to ready for review state 17:07:14 3. MK-android: discuss with Lorenzo and Arturo about true async tests in 17:07:17 the JNI environment 17:07:20 EOF 17:08:45 Worked on releasing ooni-backend and ooni-probe, Upgrade ooni-backend cannonical bouncer and collector, Furthert developing/testing OONI infrastructure deployments. --EOF 17:09:03 Last week I created a detailed workplan for myself re OTF deliverables and I reached out to potential OONI partners. Today I wrote some "informed consent" documentation, mapped out the feedback that we received from Harvard CyberLaw Clinic, updated OONI's license (minor edit) and update the legal section of OONI's current github informed consent policy (you can view the pull request here: https://github.com 17:09:09 /TheTorProject/ooni-spec/pull/55/commits/e8cacd91db981f05ef026c7beed67c0561a83dfa). 17:09:14 landers: it would actually be ideal if we could get that completed by the end of this week, since it's blocking on having support for reporting to OONI collectors in MK. Do you think that's doable? 17:10:49 hellais: yep yep; will do 17:10:59 landers: cool 17:11:06 ok I think we can now move into the items on the agenda 17:12:00 #topic limiting the usage of ooniprobe in at risk countries 17:12:23 hellais: what do you exactly mean with limiting? 17:12:36 Over the next days I'll be: (1) writing a privacy policy for OONI, (2) writing relevant "informed consent" documentation for Harvard Cyberlaw Clinic, (3) Contacting the OTF Legal Lab with the aforementioned documentation_ 17:12:41 and continuing discussions on advice for the creation of a robust 17:12:47 "informed consent" policy/procedure 17:13:25 (4) Reviewing the Citizen Lab's proposed category codes for test lists EOF. 17:14:45 sbs: the Harvard Cyberlaw Clinic have raised concerns in regards to OONI'S data collection models 17:15:35 agrabeli: okay, so limiting means preventing them from running? 17:15:47 specifically, they argue that the means for collecting data via OONI do not meat basic rules for ethical standards, since the individual risk of running ooniprobe in "red flag" countries does not outweigh the potential benefits 17:15:55 potentially 17:16:07 sbs: I think these are some hard questions we should be asking... 17:16:23 ideally we would like academic researchers to use ooni 17:16:52 but it seems that using OONI would not meet IRB ethical standards 17:17:12 agrabeli: i'd hope that concern is contextualized in terms of some demographic, like normal individuals? 17:17:40 willscott: yes 17:17:41 i feel like there's context and that it might be okay for an advocacy group to run the measurements, but we want to be cautious advertising to individuals when there's potential danger 17:18:16 it's considered much safer when diplomats, for example, run ooni in high risk countries, since they enjoy immunity from prosecution 17:18:54 sure, but diplomats often have exceptional vantage points 17:19:12 So to better re-phrase limiting means imporving OONI's informed constent without posing any software limitations? 17:19:54 i'm happy to take a look on ooni's position around ethics. I managed to get satellite through that gambit, and a bunch of it is perseverance and sticking to what we think is safe 17:19:57 anadahz: I think the hard question here is whether and to what extent we should be limiting the use ofthe software in certain countries or networks 17:20:35 because no matter how informative and robust an informed consent policy is, that still does not deem the means of collecting data as "ethical" under standard IRB rules on ethics 17:20:55 ooni is already being used in academic reports, and hasn't yet been directly flagged by an IRB 17:21:10 most IRBs won't even touch it because the network measurements don't fall under their definition of 'human subjects' 17:21:36 willscott: that's good to know 17:21:48 so what we're really doing is setting benchmark norms for the ethicists who have embedded themselves into the network measurement academic community 17:22:01 and those continue to fluctuate quite a bit 17:22:33 indeed 17:23:18 so in terms of sharing their feedback with you all, they are suggesting that we limit OONI in "red flag" countries to diplomats and VPNs - thoughts on this? 17:23:33 *further thoughts 17:23:52 Technically speaking limiting OONI software is not ideal (at least not from my view point). Even if it was desirable to do so the software can't be limited since it's based on a free license and should not pose any restrictions to the users running this software. 17:23:55 something worth looking at is also this: http://networkedsystemsethics.net/ 17:25:57 agrabeli: I'd say that, in any case, if there should be a mechanism for diplomats and the like to run the software, there should be a way to bypass the block similar to adding a flag on command line or typing "I HAVE UNDERSTOOD" 17:26:05 * sounds like 'we know better than you what is good for you'. information is good, but no reason to be patriarchal 17:27:09 * nobody has ever gotten in trouble for collecting network measurements 17:27:21 (meaning risks are purely speculative) 17:27:28 sbs: But even if we do so what effect this will have? Get more people scared? 17:28:17 anadahz: I don't know and am not happy about that, my comment was purely that it would be suboptimal to prevent it from running without any form of bypass 17:28:39 * ooni is currently sufficiently technical to operate that only users who understand the risks of surveillance and that it will be visible to their ISP are able to collect measurements 17:28:39 also, how would you prevent it from running? using client code or using the bouncer? or how? 17:29:39 as I said technically right now ooni-probe requires a new license to even do this, but I think we are currently discussing of the possible good/bad outcomes? 17:29:58 anadahz: why it does require a new license? 17:30:06 agrabeli: do we need to respond to the harvard people? what are the next steps from your perspective? 17:30:49 willscott: Yes, I'll be replying to the Harvard people this week. 17:31:23 I have implemented some of their feedback, re the legal section of the informed consent policy and the software license 17:31:57 I plan to ask them whether they have contacts with diplomats or know who we could reach out to for this 17:32:02 i would argue that we will include appropriate warnings, but that it is infeasible technically and due to core model to restrict access to the software 17:32:09 so as to reduce risk in red flag countries 17:32:35 what is the risk of ignorning what harvard people advocates for? 17:32:42 But I would also like to present to them OONI's stance on their suggestion regarding the question that I raised 17:33:24 sbs: There is no risk, but we have asked for their advice and so I think it's good to have discussions and to work together towards the best possible framework for informed consent 17:33:34 sbs: for what i know it's inappropriate to limit usage of a software in BSD-2-clause (ooni-probe license) 17:34:08 That said, we don't have to blindly apply everything that they tell us, but I think it's good to have these discussions, possibly re-evaluate our policies and so on 17:34:10 it’s not so much ignoring Harvard, but ignoring - leading/key academic institution. Agree with others that pro-actively thinking IRB approval and issues helpful for broader deployment and use in academic research 17:34:57 sbs agrabeli I guess the risk only happen, if some OONI-user get trouble, and OONI willingly underestimate the risk analyzed by Harvard (always keeping in mind, that lawyer are more paranoid than tor developer) 17:36:23 so to my understanding, evenryone disagees with the idea of limiting OONI in "red flag" countries? 17:36:27 anadahz: I see your point about the license... however you can code it such that if you run in country X it will exit() when it finds that... from the license point of view, I don't think this violates any licanse 17:36:46 agrabeli: yes, I don't like that 17:37:36 FYI an old discussion regarding ethics on networks measurements and informed consent: https://lists.torproject.org/pipermail/ooni-dev/2014-December/000205.html 17:37:38 i don't like it either. i don't think i'd trust ooni / harvard / some central body to decide what the 'red flag' countries are? 17:38:45 I also think it's not really going to be feasably for us to be able to assess ALL the countries of the world and identify all the ones that are red flag. That is there will probably always be some country that would be red flag that we haven't looked at 17:39:10 willscott: I agree with you. Though just a clarification: They labeled certain countries as "red/yellow/green" flag based on research that we previously asked from them, in assessing user risk in those countries. 17:39:23 I also don't like this and any restriction on OONI software components pre-imposed to any/specific users 17:40:35 Overall I am also sceptical towards the colour flagging of countries, esecially since risk is contextual and depends on many parameters that keep changing. 17:40:53 hellais: additionally how often these evaluations are being updated, a country that is today on a yellow flag could be tomorrow on red flag for instance after a specific occurence of an event 17:41:22 I also agree with you all that limiting OONI in certain countries is against OONI's core principles, and that there are is no evidence to back up speculative risks. 17:41:53 ok so I guess we have reached a consensus that limiting usage of OONI is not going to be either feasable nor optimal. Do we want to perhaps table this until after having gotten more feedback from the harvard people and decide on how to go abouts with informing users without impacting their ability to run it? 17:42:19 sbs: Actually even coding it to act like this is against the license, for some background references check 'free software and military restrictions' 17:42:34 However, an open question: What responsibility should/could OONI have if users do face various forms of retribution in the future, once OONI is more accessible to broader audiences? 17:43:24 agrabeli: do you mean money retribution? 17:44:14 anadahz: it's actually not against the BSD license since you are not saying "if you are person X you can't run this software", but rather it's a "feature" of the software to detect the country of the vantage and not run "when it's part of some set of countries". 17:44:25 anadahz: uhm, I am not convinced, perhaps we can discuss this later / offline 17:44:37 vecna: I am referring to potential consequences (arrests, fines, etc.) 17:45:10 anadahz hellais: yes, I agree with hellais regarding the BSD license 17:46:17 i think it's reasonable to have more circumspect modes of operation and documentation on why those are more appropriate 17:46:47 willscott: for example? 17:47:24 for example a trickle of measurements that look like they could be the user accidentally clicking a link to a sensitive domain and then backtracking 17:48:00 i think i agree with hellais that we have reached concensus on the immediate question. we can maybe schedule some time to work on text around this issue, but maybe move on to next agenda item? 17:48:24 willscott: ah, neat... and you would enable that operating mode in specific countries? 17:48:43 Agreed. I'll circulate relevant doucmentation over the next week. 17:49:07 ok good. moving on.. 17:49:11 #topic inclusion of a VPN endpoint inside of the raspberry pi distribution for OONI to run tests 17:49:28 ... fo trackography 17:49:39 thanks! hi, I'm Claudio Agosti, my first meeting here 17:49:52 I'm running a data collection project (trackography) and I would benefit of many "testing point" from different countries. 17:49:52 So In theory, if the raspberry.py of OONI would be considered like an "infrastructured", I can use some of them, and I can dispatch around the world the same kind of hardware/software combo. 17:49:53 But my tool use phantomjs (and maybe other javascript sandbox tools) so is heavy in computation, can't run in the RSBPY. 17:50:07 So in theory a good solution can be having proxies. OONI raspberry runs some TLS/oauth authenticated proxy, only some node can be used, and they will forward my traffic. 17:50:07 but I know that OONI raspberry.py declare, in the users interest, the kind of traffic performed. mine are just HTTP GET request over a public list of website (without any special parameters), but the proxy imply a potential arbitrary traffic. 17:50:07 So can be an option in user side (a checkbox to tick?), and/or can be implemented a filter in the proxy (permitting only HTTP GET), and/or can be a detailed accounting of the operations done via the proxy. 17:50:13 Generally speaking, if a fellowship get accepted that distributed infrastructure can became handy. I can take care of the proxy code/settings/auditing in that case. 17:50:13 Every new device will contribute also to OONI network. 17:50:29 (EOF) 17:52:34 vecna_: when you say "only some node can be used", you mean that some raspberry would run trackography? 17:52:40 this feels like it dovetails with orchestration 17:53:46 sbs: I mean that I don't need all the nodes, just some. so can be an option not active by default. for sure - RSPBPY will never run trackography - that is the reason to have a proxy 17:54:17 which i guess would be setting the initial expectation that we don't have a way to do this sort of central coordination of 'pushing' measurements now, and it'll be ~6 months before we get there at the current schedule 17:54:21 vecna_: got it 17:54:24 willscott: ah, good, I'm not aware of that software. but at the moment the fellowship is not yet confirmed, so I've not made plans in details nor research 17:54:50 a study of internet controls in Venezuela was recently completed by several ngos there. They used OONI as the testing tool. Let me know how best to schedule briefing ahead of report lauch with key ooni folks 17:55:29 catfish99: great! is this a time that works for you? maybe the same time but a different day this week we can dedicate to your briefing? 17:55:42 Hm.. that's an interesting inclusion feauture, however given the fact that VPN has the (bad) habit of rerouting all network connections to a specific gateway it may causes some problems with routing or awkward ooniprobe measurement reports 17:56:00 catfish99: i think ideally tomorrow / wednesday to make it easy for agrabeli 17:56:11 willscott: for me a suitable option is also patch the software having a proxy and deploy these (customized) raspberry to be used by my network. but means loosing all the nodes available in OONI 17:57:00 vecna_: doing your own deployment may be an easy thing for you to do short term. especially if you just grab a standard linux image with something like resin.io you should be able to do that fairly painlessly 17:57:07 anadahz: I was not thinking to VPN also to avoid any network layer mistake. HTTP GET for me are enough, that's why an HTTP proxy fit better 17:57:25 willscott: yes but is what I want avoid 17:58:16 yes I think the orchestration is necessary to have this be integrated in a way that it doesn't interfere with the network measurements of ooniprobe. Having a proxy means that whatever bandwidth is required for your testing is multiplied by a factor of 2 17:58:19 willscott: you know, separation of duties :) if I can just help in a small software side and benefitting of a worldwide network, much better. btw all the data collected are open data, so can be considered as part of the measurement 17:59:07 hellais: I agree but, with an API that declare when the device is running and when is not, I can distributed the testing only in the "empty" moment 17:59:34 vecna_: right. that's part of what we're calling orchestration 17:59:49 ack 18:00:49 vecna_: This would be nice and pretty straight forward to do, ideally it will be nicer for the user to decide if they would like to run trackography tests ut I don't see any issues with that. 18:00:50 so, I don't need an answer now, no consensus need. raising this interest was my only goal today, and get some primary feedback 18:00:57 i guess for now, keep us updated on your progress and track our progress on orchestration 18:01:08 i don't think we have tickets / bugs super well tagged at the moment, which is a separate issue :) 18:01:19 good, thanks 18:02:30 catfish99: Do you think that the findings should be first discussed publicly or is it OK if some/any of the key findings are discussed here? 18:04:14 i was an advisor to the project and authors were keen to brief and have a conversation with the ooni community ahead of the public report launch 18:04:59 it is more a pilot project - so feedback is helpful! 18:06:11 seems great to have a blog post ready to go in coordination with the release 18:06:35 agree! 18:06:52 that’s the interest to have a briefing :) i’ll follow-up and coordinate with you 18:07:02 catfish99: yes we would love to give feedback and look at the report. Andres showed me an early version of the report in valencia some months ago. 18:07:42 there report is ready in spanish. It’s being trnaslated, so a english version is available 18:07:46 too 18:11:14 catfish99: When do you want to make this report public? 18:12:19 report launch is later this month. i can’t recall specific date. will post to list 18:14:43 other agenda items? 18:15:24 I think we are a bit overtime but if the rest of the people are OK with this we can move on 18:15:56 yes let's try to at least briefly cover the other items 18:16:16 I would table the trac vs github discussion as I think it's going to be a big rabbit hole that we shouldn't dive into now 18:16:35 #topic possibility to introduce a kind of tickets sprint 18:17:08 thanks all 18:18:05 I think this idea of doing some ticket sprints to close invalid tickets is a very solid idea. When do we want to do this? 18:18:56 I think it makes sense to do this in regular intervals, but in short periods like 10-15 mins. 18:19:47 hellais: do you think we should all be online too coordinate, or can we do this asynchronously? 18:22:34 I guess in the end it's not essential that we are all online at the same time, though it's probably smart to be mindful of timezones to be able to reach out to other during that period when questions arise about them 18:23:38 I plan to set some time aside tomorrow afternoon (at around 16:00 CEST) to clean up the tickets on trac. 18:25:02 hellais: Sounds a plan I 'll try to be around before/after and co-ordinate on triaged, undecided tickets 18:25:23 cool. 18:25:25 * and invalid 18:25:25 moving on 18:25:41 #topic options on how to collaborate better with the metrics-team 18:25:49 anadahz: did you have something specific in mind regarding this? 18:26:16 I guess one thing that we should begin doing is to attend their meetings and see what it is that they discuss there that could be relevant 18:26:45 The time and date is Thursday at 14:00 UTC in #tor-dev on OFTC 18:27:03 True, metrics-team runs bi-weekly IRC meetings, next is on: May 5, 2016 18:28:55 I can manage to attend the next one but I'm not sure if I can follow 18:30:41 hellais anadahz: okay, I will also be around around 16:00 CEST for the tickets cleanup 18:34:07 I can also help tomorrow at 16:00 CEST for the tickets cleanup 18:35:12 ok let's move onto the next item. 18:35:29 #topic provide list of easy tasks 18:35:44 this seems like part of the bug cleanup? 18:35:57 yes exactly I was about to say 18:36:16 I think that while cleaning up the bugs we will probably want to flag some of them as easy. 18:36:38 Also I think that some time needs to be spent in creating new issues for all the things that we have to do. 18:36:53 In particular we should begin creating issues and milestones for the OTF deliverables. 18:37:42 though this raises a age old debate in which issue tracker we should be using. 18:37:55 hellais: I was about to say so :-) 18:38:11 the current state of tickets is a mess, in that there are a bunch of tickets in trac that are not on github and vice-versa 18:38:33 as I have already expressed in the past I am quite against us using trac 18:39:25 I think we shouln't really mix these 2 topics 18:39:27 the reasons have mainly to do with the terrible usability of trac, the fact that we don't have separate issues for each of the software components of OONI, the fact that it's not tightly integrated into the code review process 18:40:12 We just need a simple and clear "page" that explains some easy things a person was never involved this OONI can do right away 18:40:58 hellais: endorsing your opinion on trac and expressing my preference for github 18:41:35 currently both Trac tickets and Github issues don't provide this information and a person needs to understand the cryptic language that is being used in bug reports 18:42:18 anadahz: I think that having a page for something like this is prone to making the information on such page before very quickly obsolete. We can just introduce a "easy" label to the tickets and flag issues that are easy and have a link to the formed serach query somewhere in the readme 18:42:21 anadahz: do you suggest a sort of CONTRIBUTING.md? 18:42:54 hellais: so let's make sure that we update this page then 18:43:23 sbs: Yes but making it available on OONI's main website 18:43:24 hellais: +1 on easy... maybe we can also say to people (if we don't say already) that we're available to discuss / review patches / help at a specific time? 18:44:24 sbs: hellais we should not impose that people should code in order to contribute 18:44:53 anadahz: makes sense, you're right 18:44:59 anadahz: not all tickets have to be about code related tasks. 18:45:24 there are many ways on how they can contribute but these are not currently either on Github issues nor in in Trac tickets 18:45:59 anadahz: anyway, I understand the value of saying somthing to the website but I also have the concern that the more distant something is from git repository, the less frequently developers see it and/or remember to fix/update it 18:46:06 Other than that when people see tickets tend to run and are afraid to contribute by using them 18:46:19 anadahz: hehe 18:46:36 anadahz: what do other projects do to solve this needs? 18:46:37 sbs: Currently OONI's website in on git 18:46:44 anadahz: then maybe we can do something where we put the modes of contribution that are static in a document and the ones that are going to change inside of tickets? 18:47:44 anadahz: sure, I know, but I tend to think that changes across repositories after a change are less likely to happen than changes within the same repo... in any case mine was minor objection that we can table 18:47:55 like the static page can talk about contributing measurements, adding lists of URLs to test to the citizenlab test lists, searching through the explorer for interesting cases of censorship etc., while for tasks that once they are done they don't have to be repeated we use issues? 18:48:01 sbs: torproject for instance has different categories on how people could help 18:49:23 hellais: sbs we can add a Contribute file in all repos that is going to be called by ooni-web git repo when the site is being compiled and published 18:49:39 hellais: exactly! 18:50:14 sbs: ref: https://www.torproject.org/getinvolved/volunteer.html.en 18:50:23 anadahz: good point about torproject, was checking it out! 18:50:52 * sbs is hungry #nudging :-P 18:51:33 anadahz: re the contributing file, I was also reading that there is limited possibility to customize a new contribution / issue... maybe we would like to take advantage of this? 18:52:17 yes indeed I think we have gone way to much overtime at this point. I would say we continue going through the remaining points in next weeks meeting. 18:52:36 sounds great 18:52:44 (e.g. https://github.com/isaacs/github/issues/99) 18:53:57 sbs: perhaps we should use gitlab and setup out own structure 18:54:35 (here! https://github.com/blog/2111-issue-and-pull-request-templates) 18:55:19 just FYI Github it's the only non free infrastructure that currectly OONI uses considering that we will be using AWS servers only for backup 18:55:22 anadahz: hmm, I'd rather continue using github: the more infrastructure, the more maintainance burden 18:55:35 sbs: +1 18:56:42 anyways we are not going to reach consensus on this today, so let's for the moment table this and defer to next week 18:57:01 thanks for attending the meeting. ciao! 18:57:03 sbs: there is still maintainace on github, ie: learning to work the github way 18:57:24 anyway we can disucuss this more on the next meeting 18:57:31 #endmeeting