13:58:52 <hellais> #startmeeting OONI Community Meetin 2020-08-25
13:58:52 <MeetBot> Meeting started Tue Aug 25 13:58:52 2020 UTC.  The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:52 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:59:31 <slacktopus> <agrabeli> <here> Hello folks! Welcome to the August OONI Community Meeting. :):ooni::party_parrot:
13:59:51 <slacktopus> <agrabeli> Hope you're all doing well!
14:00:28 <cyberta> o/
14:00:35 <slacktopus> <agrabeli> We skipped the last 2 community meetings because in June we had the Internet Measurement Village almost every day, and in July there was RightsCon Online during the last week. Hopefully you attended and enjoyed both! :)
14:00:36 <slacktopus> <hellais> Hello!
14:00:48 <slacktopus> <sbs> o/\
14:01:08 <slacktopus> <xhdix> :wave:
14:01:28 <slacktopus> <agrabeli> If you missed the Internet Measurement Village, you can find all of the recordings (and the slides for each presentation) here: https://ooni.org/post/2020-imv-slides-recordings/
14:02:00 <cyberta> thanks for sharing
14:02:04 <slacktopus> <agrabeli> And you can subscribe to the OONI YouTube channel to view the presentations directly (as well as future content): https://www.youtube.com/c/OONIorg
14:02:42 <slacktopus> <agrabeli> Please feel encouraged to present yourselves asynchronously as you join! :)
14:03:10 <slacktopus> <agrabeli> And as a reminder, the topics discussed during today's meeting are available in this pad: https://pad.riseup.net/p/ooni-community-meeting-keep
14:03:22 <slacktopus> <agrabeli> Please add any other topics you'd like to discuss today
14:04:00 <slacktopus> <agrabeli> That said, let's get started!
14:04:12 <slacktopus> <agrabeli> #topic 1. Proposal to add RiseupVPN to circumvention tool testing suite [cyberta, kwadronaut?]
14:04:13 <cyberta> hi, I'm new here. I'm participating in the development for RiseupVPN and wrote down the first topic :)
14:04:21 <cyberta> and hi kali1 :)
14:04:44 <slacktopus> <agrabeli> cyberta: Fantastic, thank you! Would you like to share a few more words about this topic?
14:05:19 <cyberta> we would like to implement measurements for Riseup to detect if their gateways or the provider API is blocked
14:05:20 <slacktopus> <agrabeli> (cyberta: And welcome! :) )
14:05:51 <cyberta> I still need to get an overview of ooni as a whole, in order to know where to start :)
14:05:53 <slacktopus> <hellais> cyberta: is this an HTTPS service?
14:05:55 <slacktopus> <hellais> How does it work?
14:06:07 <cyberta> it is a vpn based on openvpn
14:06:10 <slacktopus> <hellais> Do you have links to code or documentation where we can better understand how this works from a technical perspective?
14:06:12 <cyberta> and supports obfs4
14:06:22 <cyberta> yes 1 sec
14:06:23 <kali1> the main provider entrypoint (over tls) is already added to the web connectivity list, but we still have to automate analysis a bit
14:07:01 <kali1> but we'd like to go further and were thinking about maybe having some builds integrating with the ooni engine to properly diagnose what's the situation in different places
14:08:00 <slacktopus> <sbs> what do you mean precisely with "builds integrating with the OONI engine"?
14:08:07 <slacktopus> <sbs> what would you like to integrate?
14:08:12 <cyberta> actually our docs are quite outdated :/. We need to work on that. Some references are https://riseup.net/vpn, https://bitmask.net/en/features/vpn,  https://0xacab.org/leap/bitmask_android, https://bitmask.net/en/features/vpn
14:08:38 <kali1> basically there's an initial bootstrap of config files (over tls, so that dns block is a first thing to avoid) that describe different gatewys and transports, and from there clients can try different combinations of those. we've seen that gateways also regularly get "burned" (my guess is that they get added to proxy/vpn blacklists), it'd be helpful to stay one step ahead
14:09:27 <slacktopus> <sbs> okay, so what you are thinking about is implementing the bootstrap in ooni/probe-engine?
14:09:32 <cyberta> we would like to measure if the openvpn gateways and its supported pluggable transorts
14:09:53 <kali1> the desktop client is go-based, we had thought that we could have a special build that basically runs ooni probe diagnostics specific against the provider config bootstrap, and the different gateways and their transports - if that makes sense
14:10:33 <slacktopus> <sbs> how do you integrate with OpenVPN? how large is the build?
14:10:45 <kali1> probe-engine -> yep (i haven't looked in detail into this, though)
14:11:09 <cyberta> sbs you mean the size of our app?
14:11:17 <slacktopus> <sbs> yes
14:11:18 <cyberta> 8 mb or so
14:11:23 <kali1> that differs for android and desktop, but (desktop mainly, cyberta does android) right now we just invoke the binary
14:11:38 <slacktopus> <sbs> I see
14:11:53 <kali1> desktop is a bit bulkier atm since it ships qt statically, around 30mb
14:11:59 <slacktopus> <sbs> thanks
14:12:30 <slacktopus> <agrabeli> https://github.com/ooni/probe-engine
14:12:31 <slacktopus> <hellais> Do you link directly to openvpn?
14:12:45 <slacktopus> <hellais> Or do you spawn a subprocess and pilot it via stdout/stderr?
14:12:55 <cyberta> we integrate it as a library on android
14:13:01 <slacktopus> <hellais> on desktop
14:13:08 <slacktopus> <hellais> ?
14:13:09 <kali1> desktop: we expect the binary to be there - although we were looking into using openvpn3
14:13:25 <slacktopus> <hellais> hm
14:13:55 <slacktopus> <hellais> so you look for `openvpn3` in `/usr/local/bin` or whatever?
14:14:10 <slacktopus> <hellais> as in you don’t ship the actually binary, but expect the OS to ship it?
14:14:15 <slacktopus> <sbs> cyberta: do you integrate `openvpn3` as a library on Android?
14:14:28 <kali1> openvpn3 would be a future option to use it a a (linked) library
14:14:31 <cyberta> we don't use yet openvpn3, it's a plan for the future, right now we depend on opnevpn 2.4
14:15:09 <cyberta> and we integrate on android openvpn as libs
14:15:24 <kali1> desktop: that depends on the distribution mode. for snaps, for instance, openvpn is shipped. deb as a dependency; osx and windows installers ship a openvpn that we build ourselves
14:16:22 <slacktopus> <hellais> do you need the OONI Probe Desktop app?
14:16:34 <slacktopus> <hellais> You mentioned above that you would like to make a custom version of OONI Probe Desktop
14:16:47 <slacktopus> <sbs> maybe it's a stupid question, but... did you folks consider using Wireguard? (mainly out of curiosity)
14:16:49 <slacktopus> <hellais> Do you need a desktop testing client or would it be sufficient to have a CLI build of it?
14:16:51 <cyberta> I think we need just one app, can be the mobile client or the desktop client
14:16:53 <kali1> my main question at the moment (any pointers welcome) is if that mode of using probe-engine built-in in the app itself would sound like a reasonable idea
14:17:11 <kali1> wireguard, there is a post about it, one sec
14:17:42 <kali1> https://leap.se/en/about-us/news/2020/wireguard
14:18:06 <slacktopus> <hellais> The issue is that if you are going to make a fork of OONI Probe desktop (which is an electron app), to get your new custom test in, you will also have to modify probe-cli and in turn probe-engine to get it in there
14:18:39 <cyberta> I think it would be also interesting to have it integrated in any of the regular clients, if this is doable
14:18:40 <kali1> my rationale (and I think some of you guys mentioned this in some congress, unless I misunderstood) is that we could have a built-it diagnosis tool by calling the probe-engine test that we need, rather than asking users to install ooni-desktop or whatever
14:18:42 <slacktopus> <hellais> If you test is not going to be upstreamed, which if it’s reliant on an external binary it probably would not, it’s going to be very painful for you to stay in sync with the latest OONI Probe versions
14:19:01 <kali1> aha
14:19:13 <slacktopus> <sbs> thanks for the link on wireguard, /me is reading!
14:19:18 <slacktopus> <hellais> So I am trying to better understand what your use-case is, because if you are just targetting linux users or similar (I gathered you currently mostly have linux users), maybe that is better
14:19:34 <slacktopus> <hellais> maybe it is better to just integrate your test into probe-engine and then use the miniooni CLI
14:19:42 <cyberta> we are targetting users on all platforms in general
14:19:43 <kali1> so, if we make it so that it doesnt rely on ext binaries, I guess we could upstream the vpn test, and just link against probe-engine to do the needed tests? (no need to fork any ui)
14:20:06 <kali1> yep, windows would be important here
14:20:10 <slacktopus> <hellais> Which miniOONI CLI has no sort of API promise as probe-cli or probe-desktop
14:20:11 <slacktopus> <hellais> So it’
14:20:13 <slacktopus> <hellais> s
14:20:22 <slacktopus> <hellais> it’s also with no warranty whatsover, but it might break less than that
14:21:50 <cyberta> probe-engine is integrated in all ooni clients right?
14:22:09 <slacktopus> <hellais> it’s a bit more complicated than that
14:22:12 <kali1> hellais: can you point us to relevant docs about what's the expected structure to integrate a test into probe-engine? (and, does it look like adding the openvpn3 dependency would be a problem?) - also, I don't want to get into a rabbithole or sorts aobut details, happy to not use too much space now and continue discussion somehwere else :)
14:22:55 <slacktopus> <hellais> @sbs can you share our architecture diagram, I think it would help
14:23:01 <slacktopus> <hellais> ?
14:23:40 <cyberta> if we integrate our measurement development efforts into probe-engine, there's 'only' UI work to be done to run the tests from the different clients?
14:23:44 <slacktopus> <hellais> But yeah it’s maybe a much longer discussion that can happen after the meeting
14:24:04 <slacktopus> <sbs>
14:24:29 <slacktopus> <hellais> The bottom line is that I would say, if you can start from doing a test in probe-engine, but from going from a probe-engine test into being a fully fledged OONI Probe Desktop UI rich test, it’s going to take a lot of time and effort
14:24:51 <slacktopus> <hellais> That is not to say it cannot happen, it very well can, but we can’t guarantee that
14:25:55 <cyberta> ok, and the fall back would be the miniOONI client, we can point riseup volunteers to, right?
14:25:56 <slacktopus> <sbs> as for where to start from, check `./experiment/example` and generally the `./experiment` folder
14:26:06 <hellais> this is the architecture graph of probe: https://share.riseup.net/#-qmYU0Btl7EGc8ShgWytew
14:26:08 <cyberta> thanks
14:26:38 <slacktopus> <hellais> yes exactly, integrating into miniooni is in any case the first step that you have to do no matter what
14:26:48 <cyberta> ok
14:27:00 <slacktopus> <hellais> I think the chance of us linking to any C/C++ code is very slim, if not impossible
14:27:39 <slacktopus> <hellais> We might be willing to officially support it with the spawning of a subprocess approach, but that would only work desktop
14:27:54 <slacktopus> <hellais> This later approach is how we are going to integrate the little-t-tor binary
14:28:25 <cyberta> what is the little-t-tor binary?
14:28:31 <slacktopus> <sbs> `tor`
14:28:32 <slacktopus> <hellais> Once we have the test in probe-engine, then we can start thinking of how to expose it’s functionality with the public probe-cli command line interface (which we have a committed API for)
14:28:37 <cyberta> ok
14:28:40 <kali1> re. linking: ok, good to know - but still makes sense for us to use whatever network probing primitives are in probe-engine and configure a test against our vpn endpoints based on that (miniooni would be a plus)
14:28:46 <slacktopus> <sbs> as opposed to Tor (the org)
14:28:47 <slacktopus> <hellais> Then we can proceed to developing a user-interface for it inside of probe-desktop
14:28:57 <slacktopus> <hellais> thinking of how we are going to ship the binary to probe-desktop and all the rest
14:29:13 <slacktopus> <sbs> network primitives in probe-engine: check `./experiment/urlgetter` and/or `./netx`
14:29:24 <slacktopus> <hellais> the timeline is probably 6-12 months for a test of this complexity (i.e. that is not pure golang code)
14:29:46 <slacktopus> <hellais> Does this address your questions?
14:30:22 <cyberta> yes thanks
14:30:52 <cyberta> I'll hang around here, and probably kwadronaut will appear here too at some point
14:31:02 <slacktopus> <sbs> great!
14:31:09 <slacktopus> <hellais> Sounds great, let us know if you have any other questions and we can discuss this more in depth in here
14:31:11 <slacktopus> <sbs> ping us if you have questions :)
14:31:17 <slacktopus> <hellais> or in the ooni-dev channel
14:31:27 <slacktopus> <hellais> (which is also bridged with IRC)
14:31:29 <cyberta> what is better? here or ooni-dev :)?
14:31:35 <slacktopus> <hellais> I think ooni-dev is better
14:31:38 <slacktopus> <sbs> I'd say ooni-dev
14:31:40 <slacktopus> <sbs> lol
14:31:42 <cyberta> ok
14:31:43 <slacktopus> <hellais> :)
14:31:47 <cyberta> great
14:32:15 <slacktopus> <agrabeli> Great! Unless there's anything else to discuss atm on this topic, let's proceed to the next.
14:32:25 <slacktopus> <sbs> :) == :) ?
14:32:33 <hellais> hahahah
14:32:49 <hellais> the slack bridge converts :D into :)
14:32:49 <cyberta> if have no further questions :)
14:32:58 <kali1> ))
14:33:06 <slacktopus> <agrabeli> #topic 2. Measuring an internet blackout (Proxy support for speaking to backend services:  https://github.com/ooni/probe/issues/985 ) [xhdix]
14:33:18 <slacktopus> <agrabeli> @xhdix the floor is yours. :)
14:33:48 <slacktopus> <xhdix> Hi, A few days ago, the Internet of many users in Iran had become like a national network. About 90% of IPs were not accessible. Including OONI. Only a handful of VPNs and proxies were accessible. Users wanted to test with OONI but backend was not accessible! ( * screenshot). And on mobile, it was not possible to set up a proxy for the backend. Also, as the Internet blackouts increase every day, I'm eager to know what OONI has done so
14:33:48 <slacktopus> far to measure it. (Speed in measurement is very important because blackouts often occur at very important events.) Of course, I take this opportunity to express my special thanks to the tireless efforts of the @ooni-team, and especially to @sbs. I really appreciate it.)
14:35:20 <slacktopus> <sbs> what is your question? :)
14:35:23 <slacktopus> <hellais> Do you have more information on how the block is being implemented? What are the 10% of addresses which are reachable?
14:36:07 <slacktopus> <xhdix> _I'm eager to know what OONI has done so far to measure it *(a internet blackout)*._
14:36:26 <slacktopus> <hellais> Is this similar to the outage that happened last year ~ Nov 2019: https://ooni.org/post/2019-iran-internet-blackout/?
14:37:18 <slacktopus> <sbs> @xhdix: yeah, it's not so easy for me to answer your question
14:37:45 <slacktopus> <sbs> we're not well placed with respect to measuring blackouts and also we need maybe to clarify the scope a bit
14:38:01 <slacktopus> <sbs> is this blackout we're talking about like the one in November?
14:38:11 <slacktopus> <sbs> *November '19
14:38:28 <slacktopus> <sbs> apart from that, here are a bunch of observations:
14:39:42 <slacktopus> <xhdix> Yes.
14:39:45 <slacktopus> <sbs> 1. it's wrong that OONI first does some bureaucracy like finding out the user address, contacting the probe services, etc. and then run the measurement; we should first and foremost measure and then do all the bureaucracy (but this is not super easy)
14:40:47 <slacktopus> <sbs> 2.  if we can do the above, we can at least keep the measurements on the phone and then possibly submit later, even though the quality of what we get might not be optimal (e.g. missing confirmation from the test helper)
14:41:05 <slacktopus> <agrabeli> (re: 1 => making OONI Probe more resilient to censorship)
14:41:42 <slacktopus> <sbs> 3.  improve support for auto-proxying on both desktop and mobile (which currently suffers of a chicken and egg problem)
14:44:06 <slacktopus> <hellais> 3 => basically means using circumvention technology (tor or psiphon) opportunistically
14:47:22 <slacktopus> <hellais> The bottom line is that we are working on all 3 areas of this, which will significantly boost our resilience to handling big network disruptions as those seen in Iran
14:47:50 <slacktopus> <hellais> Unfortunately there is no quick fix we can roll-out now, because there are still many unknowns and things we will have to adjust and figure out along the way
14:48:28 <slacktopus> <hellais> @xhdix if you think there are some specific things we should be prioritising or that we haven’t through of yet, please do let us know!
14:50:36 <slacktopus> <agrabeli> @xhdix was there any particular event that motivated the censorship you refer to from a few days ago? Or does it seem that they are gradually rolling out the intranet?
14:53:16 <slacktopus> <agrabeli> thanks
14:54:19 <slacktopus> <agrabeli> @xhdix do you have anything else to add or any further questions?
14:56:02 <slacktopus> <xhdix> No. Thanks. And thank you for addressing this issue.
14:57:19 <slacktopus> <agrabeli> Thanks for raising this issue!
14:57:51 <slacktopus> <agrabeli> We have 2 minutes left, and no more topics in the agenda... Is there any other topic you folks would like to briefly like to raise/discuss?
14:58:04 <slacktopus> <agrabeli> Any news/updates anyone would like to share?
14:59:44 <slacktopus> <xhdix> Will your RightCon presentation be uploaded to YouTube? `:D`
15:00:07 <slacktopus> <agrabeli> @xhdix unfortunately not (not that I know of, at least).
15:00:54 <slacktopus> <agrabeli> That said, the IODA folks are on this channel (@ramapad & @alberto) if you have any questions (and the OONI team is here too).
15:01:39 <slacktopus> <agrabeli> So I think that's a wrap.
15:01:47 <slacktopus> <agrabeli> Thanks everyone for joining us today! :)
15:02:12 <slacktopus> <agrabeli> We look forward to chatting more in the next OONI Community Meeting, which will be hosted at the same time during the last Tuesday of September.
15:02:39 <slacktopus> <agrabeli> In the meanwhile, please feel encouraged to participate in discussions on this channels, share news/updates, and to ask any questions you may have. :)
15:02:55 <slacktopus> <agrabeli> Hope you all stay safe and healthy, and have a great day/night! :)
15:03:38 <hellais> #endmeeting