17:00:36 #startmeeting OONI dev gathering 2016-06-20 17:00:36 Meeting started Mon Jun 20 17:00:36 2016 UTC. The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:40 hi everyone 17:01:21 hello :) 17:01:38 heya 17:01:42 so let's start with the first item on the agenda 17:01:47 #topic Discuss the behaviour of ooniprobe when adding cloudfronted and https collectors 17:02:23 in https://github.com/TheTorProject/ooni-probe/pull/546 there is a new ooniprobe configuration option that allows you to se the preferred_backend 17:02:31 cool! 17:03:23 this is currently defaulting to onion, but we could potentially make it not default to the onion one and make tor become a soft dependency of ooniprobe 17:04:19 I think the ideal thing is for the next release is to keep the behaviour consistent with the old ooniprobe and not do this, but I wanted to bring this up as it's something we may be interested in doing in the future to increase the adoption 17:05:00 how are we going to use/do cloud fronting? 17:05:07 this seems like an unobjectionable plan 17:05:53 anadahz: as soon as the https collector is up and running I will configure a cloudfront to point to it. 17:06:49 basically you just tell amazon where you want their cloudfront to point to and it gives you back some xxx.cloudfront.net domain and when you pass that in the Host header to anything running on amazon it will redirect traffic to your service 17:06:53 in which CDNs are we going to do cloudfrontng? 17:07:50 could we re-deploy the meek server and get google,microsoft, and amazon with that code? 17:08:25 the current plan is to only support amazon 17:09:02 the meek server doesn't really help us that much. I mean in the end the code for doing cloudfronting is quite trivial. 17:09:25 seems fine to choose whatever as a first pass 17:09:34 i guess it make senses for ooni-probe to have fall-back support to Tor, since if for any the cloudfront collector is being blocked or amazon disrupt/stopthe service the clients will not be able to sent any reports/do measurements 17:10:04 anadahz: if amazon is being blocked it's unlikely that a direct tor connection will work either? 17:10:05 like google that decided to drop meek support 17:10:28 so the user would need to do the bridge setup at that point 17:10:29 willscott: not necessarilly, there are countries that have embargoes 17:10:58 willscott: currently there is support for fallback on obfs4 and meek in ooniprobe 17:10:59 just NK, though, yeah? 17:11:46 willscott: OONI services have been disrupted once by Amazon 17:12:05 to my knowledge the amazon cloudfront meek uses is not blocked anywhere, though I think that we should probably refrain from ever making cloudfronting the default 17:12:34 it would be quite costly and it should be always something that a power-user enables or that is used when/if the https:// collector is blocked and tor is not working 17:13:22 anadahz: yeah, but it was my fault for not paying the bill on time :P 17:14:08 hellais: well that's what happens when you rely on a businness :) 17:14:09 would users be able to choose if they want to send their measurements over Tor or a https collector? 17:14:35 all of OONI's infrastructure is not in commercial services 17:15:14 with parts of the explorer being in AWS 17:15:18 agrabeli: yes, that is what it's possible to do with the preferred_backend option. If you say preferred_backend: "https" it will prefer those over Tor collectors. 17:16:11 and this will change soon as we are going move the explorer AWS parts to Greenhost 17:17:18 okay.. are there other open design questions to discuss around the collector? 17:18:10 I guess the other question is if you think there is a need for having a more strict option that says "only use backends of this type" 17:19:07 the reasoning behind this is that there may be a user that wants to be as stealth as possible and not reveal to the network that they are using tor or connecting to ooni backends directly and therefore they would only want to use cloudfronted stuff 17:19:47 currently the preferred_backend option will fail-over to using the other less preferred options if the preferred option is not working 17:20:37 this seems fine. if the user is doing stealth mode they'll know what they're doing and can have tor not actually be callable / functional on their machine 17:21:29 but the https collector will always work so there could be some case where they will end up using that 17:21:30 thought by installing tor (ooniprobe dependency) is being started on boot 17:22:18 the whole point of this is that tor becomes a soft dependency, yeah? 17:22:32 anyways I think it makes most sense to defer this problem to when we work on making ooniprobe actually more stealth and as long as we don't advertise this as a security/privacy feature for the moment it should be good 17:23:02 willscott: yeah. In the future tor will not be a hard dependency 17:23:05 seems reasonable. is there a bug to document these concerns about what stealth means? 17:23:23 willscott: no, but I will create one. 17:24:38 ok I think this covers what we had to say about this 17:27:07 yes next topic 17:27:08 noted some of these things here: https://github.com/TheTorProject/ooni-probe/issues/553 17:27:36 #topic Agree on a release date and triage tickets to be included 17:29:19 so far there is this as the major features to be included in 1.6.0: https://github.com/TheTorProject/ooni-probe/milestones/ooni-probe%201.6.0 17:29:41 Ideally the release date should be June 30th 17:30:18 but we should aim to have a deployed https collector/bouncer and web_connectivity test helper by at least a week before so that we can do some proper testing of ooniprobe with it 17:30:26 does this seem likely to happen? 17:30:34 i'm working on it 17:31:19 but it seems very complicated and only some days ago we had https support in ooni-backend: https://github.com/TheTorProject/ooni-backend/pull/92 17:32:30 anadahz: what difficulties are you encountering? 17:33:41 i'm not encounetering really difficulties but work and figure out how ooni-backend uses the config options 17:33:58 making this an automated task is not that easy 17:34:32 and testing need some time 17:35:24 this is only the part to make certificates for ooni-backend https://github.com/TheTorProject/ooni-sysadmin/pull/59/ 17:36:03 other parts include creating a proper config file generated while ooni-backend is running 17:37:31 mainly because ooni-backend deployment was a manual task up to now 17:39:41 hellais: if some tasks are urgent than other you should mention this somehow 17:40:13 my ETA for this was end of month and I wasn't aware that you were waiting this for the 1.6.0 release 17:40:39 anadahz: can we perhaps maintain manual some aspects of the deployment and automate just that which is easily automatable? 17:41:20 anadahz: well the 1.6.0 release includes support for https collectors so yeah, they need to be deployed before we can release it 17:41:23 hellais: well yes this is ready then 17:44:47 is there anything else on this topic? 17:46:15 anadahz: when do you think we can have the new bouncer running (without the automated creation of the configuration)? 17:47:05 hellais: tomorrow, and please add a ticket for that 17:48:46 anadahz: other than this: https://github.com/TheTorProject/ooni-sysadmin/issues/58? 17:49:21 isn't this for the measurement kit? 17:51:15 yeah that was originally created for MK, but it would be the same for ooniprobe. I will create another ticket for the production one though. 17:53:52 hellais: btw don't forget that i don't have to the MK collector https://github.com/TheTorProject/ooni-sysadmin/issues/60#issuecomment-224708279 17:54:19 hellais: btw don't forget that i don't have access to the MK collector https://github.com/TheTorProject/ooni-sysadmin/issues/60#issuecomment-224708279 17:57:05 anadahz: I can give you access to it if you need it, but that was just a quick thing I setup to avoid blocking on mk development since the setup of the staging was taking more than expected. 17:57:30 once #58 is done we can potentially drop that 17:58:49 for future reference preferably use ticket dependencies and define due dates in more urgent tasks/tickets 18:03:00 anything else? 18:03:19 I think this does it 18:03:47 same 18:05:58 ok, well thank you all for attending! 18:06:01 #endmeeting