14:04:00 <hellais> #startmeeting OONI Community Meeting 2020-01-28
14:04:00 <MeetBot> Meeting started Tue Jan 28 14:04:00 2020 UTC.  The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:04:18 <slacktopus> <agrabeli> Yay! Thank you @hellais :party_parrot:
14:04:29 <slacktopus> <agrabeli> Great! So let's get started
14:04:50 <slacktopus> <agrabeli> #topic 1. Updates from the OONI team [maria]
14:05:04 <slacktopus> <agrabeli> I'll briefly get started with sharing some updates from the OONI-verse:
14:05:24 <slacktopus> <agrabeli> 1. We have published a Frequently Asked Questions (FAQ) section: https://ooni.org/support/faq/
14:06:30 <slacktopus> <agrabeli> ^^ Over the years, we aggregated some of the most commonly asked questions we've been receiving (over email, during meetings, workshops, etc.). If there are any other questions you feel we should be addressing, or anything that you feel we have not explained well enough, please do let us know -- we'd love to hear from you! :)
14:07:08 <slacktopus> <agrabeli> 2. We have published a new *OONI Glossary*: https://ooni.org/support/glossary
14:07:43 <slacktopus> <agrabeli> ^^ This includes brief explanation for terms commonly used in the OONI-verse, but it also includes many other internet-related terms which may be useful for various other projects as well!
14:08:37 <slacktopus> <agrabeli> 3. We published *OONI workshop slides:* https://docs.google.com/presentation/d/1UAxGeF1NhCXc8pT7cfWTp0NPdkWB5LInBkGfgW2syJA/edit?usp=sharing
14:09:18 <slacktopus> <agrabeli> ^^ Interested in facilitating an OONI workshop for your local communities? Please feel encouraged to use and adapt these slides! :)
14:09:50 <slacktopus> <agrabeli> 4. OONI Explorer now publishes measurements from around the world in near real-time: https://explorer.ooni.org/ :tada:
14:10:25 <slacktopus> <agrabeli> ^^ This means that as soon as anyone runs OONI Probe anywhere around the world, their test results are published there within 1 minute. :)
14:11:19 <slacktopus> <agrabeli> The above are just some selected highlights... but hopefully you and your communities will find them useful!
14:11:39 <slacktopus> <agrabeli> Please feel encouraged to share the above resources with your communities, and to share with us any feedback or requests you may have!
14:12:00 <slacktopus> <agrabeli> That's all on my end. Are there any questions?
14:13:37 <slacktopus> <agrabeli> Ah! Another important thing -- we'd like to work towards translating the FAQ & Glossary. If this is something that you'd be interested in contributing to, please ping me (here on Slack or via email at maria@openobservatory.org).
14:15:11 <slacktopus> <agrabeli> OK, let's proceed with topic 2
14:15:36 <slacktopus> <agrabeli> #topic 2. Set up a proxy for Android probe and iOS. Only for communication with OONI server [xhdix]
14:16:25 <slacktopus> <xhdix> The Islamic Republic is trying to make a whitelist for the Internet shutdown time. So most likely there will be some sites available. But `*-probe` cannot receive the test-list or send the measurements to the OONI server. This is likely to happen in Iran in less than a month. (Elections on February 21) If the mobile user can set up a proxy that accesses the Internet, he/she can easily perform the tests.
14:17:46 <slacktopus> <xhdix> Can it be implemented soon?
14:18:55 <slacktopus> <agrabeli> @xhdix that's a great question (and an important heads-up with regards to the upcoming election!). @sbs @hellais thoughts?
14:19:18 <slacktopus> <hellais> @xhdix do you know how the blocking of these backend services is happening?
14:19:47 <slacktopus> <hellais> Do you think it would be enough for us, to say, setup a *.cloudfront.org proxy in front of it and push an update to the app?
14:19:58 <slacktopus> <hellais> Or do you think some more advanced evasion is necessary
14:22:18 <slacktopus> <hellais> FWIW I see that in the last week get got 5700 measurements from Iran from 14 distinct networks
14:22:47 <slacktopus> <xhdix> 1. Unfortunately, I don't have much information 2. This service is not available in Iran right now! 3. Ability to set `HTTP` or `Socks5` proxies
14:25:39 <slacktopus> <xhdix> ( @sina Thank you for being there )
14:25:48 <slacktopus> <hellais> It’s definitely on our radar to make the reporting and backend communication more resilient to censorship, though we haven’t yet made up our mind on how exactly we ought to be doing that
14:26:21 <slacktopus> <hellais> For example we are now adding support for testing Tor and Psiphon, we could imagine using whatever circumvention tool we have measured to work to speak to the OONI Backends
14:27:22 <slacktopus> <hellais> @sbs knows better how complex it is to implement HTTPS or SOCKS5 proxy support in the testing engine on mobile, but I believe the design of the desktop engine (which will enventually end up in mobile too) is such that it should not be too hard to do
14:27:57 <slacktopus> <sina> If I’m not mistaken, having a whitlisted services/platforms that would be availalbe during the shutdown, would probably not allow the client reach the backend through the *.cloudfront.org….I mean if cloudfront was a platform that could cost them a lot to block, it would have been a good strategy. But that probably is likely.
14:28:48 <slacktopus> <hellais> All of this is to say that if you have some more information on how exactly the blocking is happening, we can try to implement a solution which may work in the short-term (ex. setup a cloudfront mirror or something similar), but I think the long term plan is to offload the problem of solving how to do circumvention to tools which are already good at that (such as Tor and Psiphon)
14:29:34 <slacktopus> <sbs> @hellais we already support this functionality because we use it when testing Psiphon. (That said, if it's really a whitelist, it may be very complicated depending on who's on the whitelist)
14:31:08 <slacktopus> <hellais> @sbs When you say we already support this functionality, you mean on Desktop?
14:31:23 <slacktopus> <sbs> yes
14:31:48 <slacktopus> <hellais> And on mobile?
14:37:27 <slacktopus> <sbs> it may be working but certainly we've never tested domain fronting with MK
14:37:36 <slacktopus> <xhdix> I think the best thing is to manually configure HTTP or Socks5 proxies. Conditions are not predictable. At the moment, they may change their mind and act again as November 2019. The only way would be a server inside Iran.
14:38:09 <slacktopus> <hellais> I mean HTTP or SOCKS proxy support for speaking to OONI backend?
14:40:06 <slacktopus> <sbs> SOCKS5 support is there but the code is C++ code so it's much more difficult to make precise statements about "it works". It used to work in 2017 but I doubt we test it at every build, so it may be broken now.
14:40:15 <slacktopus> <sbs> where broken = does not work reliably
14:41:00 <slacktopus> <xhdix> ( I don't know. Thinking about it makes me nervous. )
14:43:08 <slacktopus> <sbs> We need to plan for that. My main concern is that I see running `tor` on mobile (or `psiphon`) something that we're far from achieving.
14:44:12 <slacktopus> <hellais> I will take note of this in this issue: https://github.com/ooni/probe/issues/985
14:44:19 <slacktopus> <hellais> I suggest we brainstorm and discuss this async
14:46:11 <slacktopus> <agrabeli> Yes, we only have 15 minutes left, so let's proceed with the next topic and continue the discussion of topic 2 asynchronously (thank you @xhdix for raising this!).
14:46:25 <slacktopus> <agrabeli> #topic 3. Maxmind licensing problems [arturo & sbs]
14:47:38 <slacktopus> <hellais> So basically Maxmind, completely out of the blue, made some significant changes to the license of their GeoIP database. See: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
14:48:27 <slacktopus> <hellais> This is the thing we use in OONI Probe for transforming an IP address in an ASN and Country Code locally, so that we never have to learn about users IP addresses
14:49:35 <slacktopus> <hellais> However, since we are shipping this database, in light of their new license agreement, we would have to make substantial changes to our app, where the primary one is that we would have to force users to agree to a terms of service agreement which includes the legalese from Maxmind
14:49:54 <tomcat> I see Matomo Analytics change their IP database..
14:50:22 <slacktopus> <hellais> Which includes stuff like: >  You shall cease use of and destroy (i) any old versions of the Services within thirty (30) days following the release of the updated GeoLite2 Databases
14:50:25 <slacktopus> <hellais> or
14:50:38 <slacktopus> <hellais> >  You will maintain reasonable and appropriate technical and organizational measures for the protection of the security, confidentiality, and integrity of the Services
14:51:05 <slacktopus> <hellais> > You are responsible for the acts or omissions of any third parties with which you share the Services
14:51:22 <slacktopus> <hellais> Anyways it’s basically a pretty annoying situation which we would very much like to avoid
14:51:36 <tomcat> "Matomo will now use db-ip.com as a geolocation provider..." https://matomo.org/changelog/matomo-3-13-1/
14:51:41 <slacktopus> <willscott> it should be possible to get country-level geolocation reasonably well from other sources
14:51:48 <slacktopus> <hellais> We have consulted with a lawyer last week with @sbs to get some advice on how to proceed
14:52:11 <slacktopus> <hellais> It seems like our best option is probably to stop doing the geolocation on the device of the user, but rather doing it on some other service
14:52:50 <slacktopus> <hellais> This would mean that the threat model slightly changes, because we now for some amount of time know the IP of the users (rather than using some random IP service to discover it and then do the resolution locally)
14:53:02 <slacktopus> <willscott> if it's useful for the user to know it's country locally, you could stop-gap with something like https://github.com/willscott/ip2country
14:54:16 <slacktopus> <willscott> That one directly generates a database from BGP announcements. Not as accurate in all cases, but will do reasonably well for most end-user ISPs, is my understanding
14:54:35 <slacktopus> <hellais> db-ip.com looks really good actually, thanks for sharing that link
14:55:54 <slacktopus> <hellais> In any case the reason why I bring it up is how people feel about potentially moving the IP to country mapping into a service which is run by OONI as is integrated as part of the bouncer request
14:56:58 <slacktopus> <hellais> In the case of mobile probes, we are anyways seeing the request directly from the IP of the user for some time, so this would basically be also include then at that point the country and AS mapping in the backend
14:58:03 <slacktopus> <hellais> I suspect the long term solution may be that of relying on things that are better at figuring out where a probe is located on phone (ex. GPS or GSM tower info) rather than GeoIP, but doing that in a privacy preserving way is tricky so it’s not something we want to do now
14:58:24 <slacktopus> <hellais> Does anybody have some thoughts on this topic?
15:00:15 <slacktopus> <sbs> @hellais we should write an issue about investigating db-ip.com
15:00:40 <slacktopus> <hellais> Yeah `db-ip.com` looks really promising
15:00:55 <slacktopus> <sbs> @hellais we should evaluate @willscott code as well (ip2asn seems doable in that vein as well)\
15:01:21 <slacktopus> <hellais> Though the file sizes are bit discouraging
15:01:26 <slacktopus> <hellais> ```IP to ISP CSV, MMDB	1.02 GB	January 28th 2020```
15:01:31 <slacktopus> <hellais> ```IP to Country CSV, MMDB	31.6 MB	January 28th 2020```
15:01:43 <slacktopus> <willscott> they compress pretty well though
15:02:39 <slacktopus> <hellais> The above sizes were those of the `db-ip.com`
15:02:51 <slacktopus> <sbs> mmm, but we still need to query them, so maybe we can solve that using `mmap`
15:03:04 <slacktopus> <hellais> Yeah I was thinking that too
15:03:09 <slacktopus> <hellais> In any case I suppose more research is needed
15:03:10 <slacktopus> <sbs> the real troll would be to convert these DBs into MaxMind's data format
15:03:25 <slacktopus> <hellais> But I don’t hear anybody jumping up screaming OOMG no, so perhaps any of these options are ok?
15:05:34 <slacktopus> <willscott> @phw also has insight into the quality of various geolocation data sources
15:07:58 <slacktopus> <hellais> I took some notes from here on the relevant github issue: https://github.com/ooni/probe-engine/issues/269#issuecomment-579290019
15:09:10 <slacktopus> <agrabeli> Great! So these discussions can continue asynchronously, whether on this channel or on relevant github tickets (or elsewhere).
15:09:21 <slacktopus> <xhdix> I think the current approach is good. Changing it makes things worse. :P
15:09:45 <slacktopus> <agrabeli> Is there anything else anyone would like to add? Any questions? Updates anyone would like to share?
15:10:33 <slacktopus> <xhdix> What about bandwidth-throttling measurement? :P
15:11:08 <slacktopus> <agrabeli> Ha! That's a great question.
15:11:27 <slacktopus> <agrabeli> But that's probably a topic for another meeting, as it's a long discussion...
15:11:46 <slacktopus> <xhdix> Yeah :))
15:12:31 <slacktopus> <agrabeli> @sbs is probably the best person I know when it comes to all things performance and throttling related
15:13:20 <slacktopus> <agrabeli> Let's aim to have this discussion at the next community meeting, and/or asynchronously on these channels
15:14:26 <slacktopus> <xhdix> Whatever @sbs  prefers.
15:14:59 <slacktopus> <agrabeli> As we're 15 minutes late, let's adjourn the meeting now. The next community meeting will likely take place on the last Tuesday of February at the same time: 14:00 UTC. For details, please subscribe to the ooni-talk mailing list to receive updates: https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-talk
15:15:07 <hellais> #endmeeting