18:00:02 #startmeeting Sponsor 30 - Empowering Communities in the Global South to Bypass Censorship 18:00:02 Meeting started Tue Feb 11 18:00:02 2020 UTC. The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:10 hi folks 18:00:12 the pad for this meeting is here: https://pad.riseup.net/p/sponsor30-agenda-notes-Y1-keep 18:00:15 hi :) 18:01:02 oh gosh, i forgot to update the pad with my status 18:01:13 The first to do is to add statuses on the work done on this for last month. I see that people started doing that :) 18:02:10 np. let's give a little more time for this 18:04:27 * gaba is reading the whole list from ooni.. 18:06:54 We shared a more verbose version of that in the tor-project mailing list some days ago: https://lists.torproject.org/pipermail/tor-project/2020-February/002701.html 18:07:35 You probably want to be using the text from our monthly report in the funder report 18:09:08 yes, the funder report is in 3 months 18:09:22 For this meeting let's check if there is any dependency or coordination that needs to be done 18:10:04 i'm ready to start. i'll add ticket numbers after the meeting if that's fine with you gaba 18:10:34 yes, no problem. I can check on those 18:10:44 OONI has some stuff they need feedback on 18:10:53 related to UX that antonela will be working on for this month 18:11:04 yes, i have your stuff in my to-do list for this month hellais 18:11:17 i dont want to block ooni development 18:11:40 yeah we are not blocking on it 18:11:48 cool, good to know :) 18:11:58 we already made a release candidate with the tentative Tor test UI I made 18:12:23 for which platform? 18:12:35 macOS and windows 18:12:37 sometimes we talk about desktop but i bet we will deploy it cross-platform 18:12:45 https://github.com/ooni/probe-desktop/releases/tag/v3.0.0-rc.4 18:12:46 cross-device, sorry 18:12:50 good 18:12:54 No, this is only Desktop 18:13:02 why? 18:13:34 Because the mobile applications are a very different codebase and have different design constraints 18:13:34 is probe mobile out of scope? 18:13:45 Yes mobile is out of scope 18:13:50 oh 18:13:57 okey 18:14:24 It will probably take us much more time to get to a point where we can ship the golang testing engine on mobile too 18:14:33 i see 18:14:35 And that is a deliverable we have for another funder 18:14:50 got it 18:14:52 i tested the windows build a few days ago. i have some minor feedback that i can turn into a ticket 18:15:33 phw: that would be great! We especially need some windows testing 18:16:02 (FYI this is the issue related to the golang support in the mobile app: https://github.com/ooni/probe/issues/997) 18:16:28 great. I will check it out later today. 18:16:31 good stuff 18:16:48 do we have any other need/help for the stuff you all are working on? 18:17:00 yes 18:17:21 the big that we need coordination on is the bridgedb/ooni feedback loop that we discussed briefly in the past 18:17:39 there's #32740 on trac and i think there's also a ticket on ooni's bug tracker 18:18:02 we don't need to discuss this now but i wanted to get it on hellais's radar 18:18:36 we should soon brainstorm how exactly we want this feedback loop to work 18:19:09 the big thing* 18:19:17 You probably also want to link in that trac ticket the close github issue related to the tor test targets: https://github.com/ooni/orchestra/issues/82 18:19:45 You may also want to take note of the fact that it’s now possible for you to retrieve all tor test results with this query: https://api.ooni.io/api/v1/measurements?test_name=tor 18:20:17 oh, neat! thanks hellais, i will add that to the ticket 18:20:44 the specific issue that we don't seem to have a plan yet is how bridgedb should hand bridges to ooni 18:20:47 Example result from China: https://explorer.ooni.org/measurement/20200207T050741Z_AS56041_vF6LpJlK1box3R7IR3YWXDv4rFKXjfgmjSERc22nGpH5s58SZM & Iran: https://explorer.ooni.org/measurement/20200206T184551Z_AS197207_SjXBx35FSWpdi3W0GzpbdN9dBL8VxRwIKJeNUBUURdXP1iRJVx 18:20:55 i suppose it could then collect the results using the api you just linked 18:21:09 can it test specific briges? 18:21:17 It may be easier for casual browsing to use Explorer: https://explorer.ooni.org/search?until=2020-02-12&test_name=tor 18:22:07 gaba: aiui, the idea is that bridgedb somehow uses ooni to get its bridges tested. it then collects the test results so it no longer distributes bridges that are blocked in, say, turkey to users in turkey. 18:22:09 gaba: it currently tests all the bridges shipped as part of tor browser + the default directory authorities. We can dynamically change the test targets server-side. 18:22:16 See: https://github.com/ooni/spec/blob/master/nettests/ts-023-tor.md 18:22:44 phw: my suggestion, would be to not use the API for batch ingestion of the data, but rather we discuss some option for that. I remember writing a comment about this in a trac ticket somewhere 18:23:02 so is testing all the bridges and telling bridgedb which bridges not to give away anymore 18:23:02 It was some issue related to metrics tor data ingestion 18:23:45 hellais: but for metrics there was no option to get specific data, right? 18:24:14 gaba: can you rephrase the question? 18:24:22 hellais: maybe #32126? 18:24:39 just a sec. I'm looking for the tickets as we sjust discussed in metrics 18:24:40 Yes exactly, this one: https://trac.torproject.org/projects/tor/ticket/32126#comment:4 18:24:43 oh yes 18:26:08 The API is not really designed for batch usage, for that use case it’s better to extract the raw cans directly or to setup a copy of our MetaDB 18:26:58 hellais: by "batch ingestion" do you mean getting the bridge test results from ooni to bridgedb? 18:27:11 I think it’s fine to use the API for experimentation and to try the data out, but ideally for the long term we would use some other method 18:27:43 i'm asking because in my understanding we need a way to 1) get bridges from bridgedb to ooni, and 2) get bridge test results from ooni back to bridgedb 18:27:47 actually nevermind my question. the issue for metrics was mostly about having to sync the whole db or not. that will not be the case here. 18:28:09 by “batch ingestion” i mean setting up some system where you periodically pull in the latest data and sync your copy of “all the OONI measurements that interest you” or “all the OONI measurement metadata that interests you” 18:28:38 that would be 2. 18:28:39 about 1) what i understand hellais is saying is that they test all the default bridges but do not get specific bridges to test. 18:29:17 hellais: right, thanks for clarifying 18:29:39 gaba: yes, agreed 18:30:02 For 1, we have a target list which we can update whenever is needed and we can include in this target list even private bridges if needed: https://github.com/ooni/sysadmin/blob/master/ansible/roles/probe-services/templates/tor_targets.json 18:30:36 the tricky question for 1) is: how we can do this without making it easier for censors to discover bridges? after all, censors may run ooni probes 18:30:46 The request to the OONI Probe Services backend is authenticated (an OONI Probe needs to be registered in order to retrieve the target) 18:31:12 But yeah, they can obviously run many OONI Probes and maybe enumerate them 18:31:34 when you say "even private bridges" it means that they wouldn't show up in a public git repo? :) 18:31:50 I suppose this is more of a research question for Tor folks to tell us how they would like to partition the test targets we give out 18:32:00 > wouldn’t show up in a public git repo Yes that is correct 18:32:16 ok, great. and yes, we need to do a bit more thinking here 18:32:30 We have a system in ooni/sysadmin for managing secrets which are only accessible by people who have access to the OONI infrastructure vault 18:33:06 If necessary we could also retrieve the list at runtime from the OONI Probe Services if that works better for you 18:33:31 this has been very helpful to narrow down the problem scope 18:33:36 Currently the code for giving out bridges is pretty basic: https://github.com/ooni/orchestra/blob/master/orchestrate/orchestrate/handler/test_lists.go#L209 18:34:11 gotcha, thanks 18:34:27 We have however taken into account, in the design of the test target endpoint, the fact that we may be giving out private bridges and is the reason why we don’t, for example, use the direct bridge fingerprint as the key, but rather the hash 18:34:28 ok, so what is next step? phw: you work on a specific proposal for htis? 18:34:49 we discuss it again next meeting or via ticket/mail? 18:34:51 It is also possible to have the IP addresses of the bridge test targets be redacted from the results 18:36:10 gaba: i'll summarise what we just discussed in #32740 and coordinate with hellais once we have a better idea of how to build this 18:36:24 ok, thanks 18:39:00 added two lines to the pad about this 18:39:02 anything else? 18:39:05 I should also flag that we are going to start ramping down our effort in the DRL anticensorship grant starting from this month as we have started a new grant 18:39:25 We are aiming for wrapping up all the OONI related work by Q3 18:39:59 hellais: thanks for letting us know. That makes sense. I had ooni finishig the work on this sponsor by July 18:40:33 by September actually. 18:40:42 That is to say, that if there are things you need from OONI which may be within scope of the DRL anticensorship grant, there is no better time to ask than now :) 18:41:38 ok 18:41:42 hellais: works for me. the feedback loop is something that we're starting now 18:42:12 yup 18:43:50 anything else? 18:44:06 not from the anti-censorship team's side 18:44:10 is groot 18:45:24 ok, let's end the meeting then 18:45:30 have a very good month! 18:45:34 #endmeeting