16:00:08 <cohosh> #startmeeting anti-censorship meeting
16:00:08 <MeetBot> Meeting started Thu Aug 19 16:00:08 2021 UTC.  The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:18 <cohosh> welcome
16:00:21 <meskio> hello
16:00:29 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
16:00:46 <cohosh> feel free to add items to the agenda :)
16:02:27 <cohosh> looks like we've got some items from last time that we might want to follow up on
16:02:58 <cohosh> is there any discussion we want to have still on the v3 manifest?
16:04:00 <dcf1> I was just curious if our need had been expressed since last meeting
16:04:26 <cohosh> no, i think arlolra (who isn't here atm) was going to write up a draft
16:04:46 <cohosh> but i can do it this week if needed
16:05:41 <anadahz> hi, what is the v3 manifest?
16:05:48 <cohosh> hey anadahz
16:05:54 <cohosh> it's a webextension thing
16:06:14 <cohosh> we have a webextension that volunteers can install on firefox and chrome if they want to run a snowflake proxy
16:06:20 <dcf1> anadahz: see https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-web
16:06:23 <dcf1> ext/-/merge_requests/21
16:06:35 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/21
16:07:19 <anadahz> great!
16:07:42 <cohosh> ok i think we can move on to the next item
16:08:25 <cohosh> about support#40030
16:08:25 <tor> Uhm, which one of [tpo/community/support, tpo/web/support] did you mean?
16:08:31 <cohosh> :o
16:08:45 <cohosh> community/support#40030
16:08:52 <ggus> hey!
16:08:58 * cohosh pats tor bot on the head
16:09:03 <ggus> good bot!
16:09:16 <anadahz> :)
16:10:06 <ggus> i found a user with computer, but their computer is not installing tb-10.5, but they could install an old tor browser version. i'm trying to figure out how to fix it.
16:10:56 * cohosh checks to see if there are any more ooni results since last meeting
16:11:13 <dcf1> If I understand, this is someone other than who you were talking with before--that other person was using Tor Browser on Android?
16:11:29 <ggus> dcf1: it's the same person
16:11:32 <dcf1> ok
16:11:46 <ggus> i'm reaching out to more people in TM, just got a new contact today.
16:12:11 <cohosh> nice, that's great about finding more people
16:12:27 <cohosh> i still don't see any ooni test results
16:13:09 <ggus> i will ask this person to install ooni
16:13:27 <arma2> if we want more ideas for contacts, we could ask maria and arturo. they always seem to know people in interesting places.
16:13:55 <ggus> yeah, erin from loclab was also trying to contact more ppl
16:14:06 <ggus> i will ping maria
16:14:51 <arma2> great
16:15:30 <cohosh> did we confirm that snowflake wasn't working there? i see it in our notes on the pad but not on the ticket
16:15:51 <cohosh> well s/confirm/have evidence for
16:17:33 <ggus> cohosh: the person only tried once. we need more people to test
16:17:46 <ggus> or one that have more technical skills
16:18:17 <cohosh> okay, yep makes sense
16:19:58 <cohosh> tm=32 in the most recent bridge stats
16:20:13 <cohosh> (though it doesn't necessarily mean it's working)
16:22:20 <cohosh> anymore discussion on this topic?
16:22:38 <cohosh> i guess we will keep trying to work with users there to run more tests
16:23:10 <ggus> yeah, i was just replying to a TM person right now.
16:23:16 <arma2> speaking of snowflake blocking, i opened what i hope is a useful ticket for the future, in
16:23:17 <arma2> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40062
16:23:30 <arma2> useful for users in weird places being able to tell us why their snowflake fails,
16:23:40 <arma2> and also useful for our own measurement tools to have better assessment
16:24:39 <cohosh> yeah i understand the idea here is to use the LOG or STATUS message to pass info to tor?
16:25:10 <arma2> well, the main idea is to have snowflake think through how it can fail and how it can decide where it has failed
16:25:26 <cohosh> hmm
16:25:26 <arma2> the details of what it does with that info need to be handled too, and yes using log or status sounds plausible,
16:25:35 <arma2> but let's not get distracted from the main goal which is the self-assessment
16:26:43 <cohosh> snowflake already logs pretty much all the info we need to its own logs
16:27:12 <cohosh> you can tell from those whether your connection to STUN servers, the broker, or the proxies are failing
16:27:13 <arma2> ok. deciding which of those you would want to tell a human, and when you think it's right to tell them, sounds like the next step then
16:27:19 <cohosh> and whether the broker was out of proxies
16:27:44 <arma2> since right now if you did the full snowflake log and also you shipped with a cohosh to look at it for you, everything would be fine :)
16:28:01 <cohosh> so, if the purpose is to help us debug, the most usable way for us to get that information from users is to have it wind up in the tor log
16:28:14 <arma2> yep
16:28:15 <cohosh> because there is a user-friendly way to copy that from tor browser on both desktop and android
16:28:19 <arma2> yep
16:29:54 <cohosh> from an engineering perspective i think it makes sense to implement some callbacks for connection failure events since we are tyring to have the fully functioning snowflake library separate from the tor-specific interactions
16:29:59 <arma2> i am still thinking of an intermediate step, where periodically in the snowflake logs it says "CONCLUSION: I am failing to bootstrap because x"
16:30:28 <cohosh> but idk if a definite conclusion is helpful here
16:30:46 <cohosh> since the broker can be restarted and temporarily unreachable
16:30:48 <arma2> because "i failed to reach a foo" doesn't say whether you're about to try to reach a second foo or what
16:30:59 <cohosh> or we're short on proxies and it takes a variable number of tries
16:31:23 <cohosh> snowflake will keep trying indefinitely until the SOCKS connection closes
16:31:28 <cohosh> which i think is the right thing to do
16:31:48 <cohosh> since so many of these connection failures might be temporary
16:31:48 <arma2> yep. that is why this intermediate step isn't trivial
16:32:34 <arma2> but the better we can get at heuristics and thresholds and guesses, the happier we'll be in the long run
16:32:35 <cohosh> i still don't understand the need for the intermediate step
16:32:54 <arma2> well, imagine you have a docker image that runs snowflake tests from a vps in china
16:32:55 <cohosh> we can take the existing logs, figure out which of them are "connection events" and funnel them to tor
16:33:04 <arma2> right now the output is "what percentage of bootstrap does tor report"
16:33:26 <arma2> wouldn't it be great if the output was "how far through the snowflake connection did i get, and where did i stop"
16:33:45 <arma2> that would help you pinpoint what part of snowflake seems to be the problem,
16:33:50 <cohosh> okay is see so some mapping from these events to a progress bar
16:33:53 <arma2> and that might change, even if the tor bootstrap is always '10% doesn't work'
16:34:01 <cohosh> that is easily grep-able?
16:34:15 <arma2> maybe? i don't know.
16:34:32 <arma2> no need to soak up the whole meeting on this, in any case. there is a ticket. :)
16:35:26 <cohosh> yup, thanks for bringing this up. it will definitely make our job easier for handling those vague "i think snowflake isn't working" tickets
16:35:53 <cohosh> we don't have any more agenda items for today after this
16:37:20 <cohosh> (unless someone would like to jump in?) :)
16:37:37 <arma2> while we have .tm on the list,
16:37:44 <arma2> we should know that we're going to have ukraine on the list soon
16:37:50 <arma2> since they are seeing a spike on use currently
16:38:01 <arma2> and there will inevitably be a drop in use and we will say 'woah are they being censored'
16:38:11 <arma2> so here is our advance warning :)
16:40:28 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?country=ua
16:41:11 <cohosh> that is quite a spike
16:41:13 <dcf1> In answer to your pre-meeting questions, arma2, the Ukraine browser was FreeU Browser
16:41:16 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/22369
16:41:22 <dcf1> https://groups.google.com/g/traffic-obf/c/PhQ1_Gvjyzs/m/FCkTdrx1CAAJ
16:41:26 <ggus> i was about to open a ticket, but i was following up with romania, TM and zambia
16:41:50 <arma2> yay
16:41:52 <ggus> zambia metrics-timeline entry is ready. i think i screwed up on git, but maybe it's possible to cherry-pick
16:42:38 <ggus> and romanian people weren't very happy with the tor spike: https://www.reddit.com/r/Romania/comments/p70fsc/tor_users_in_romania_202108/
16:42:39 <dcf1> ok ggus, I'll check re zambia metrics-timeline, thanks
16:42:47 <ggus> ty, dcf1!
16:43:54 <arma2> my best guess for the romania spike is: the geoip db on the relays is now years out of date
16:44:06 <dcf1> btw some FreeU domains are on the citizenlab test-lists https://github.com/citizenlab/test-lists/commit/7e0b7eac9afda4fc396a36479e1375d067af7281
16:44:16 <arma2> so if e.g. a popular chunk of ukraine is listed as romania in those old geoip dbs, then that would explain it all
16:45:08 <arma2> dcf1 (or anyone else), do we have contacts with the FreeU people?
16:45:22 <dcf1> Not that I know
16:45:44 <ggus> freeU is the browser thing?
16:45:49 <arma2> ggus: sounds like you should put that on your list to try to brainstorm ways to reach. yes
16:46:12 <ggus> i can do that next week
16:46:15 <arma2> details here: https://groups.google.com/g/traffic-obf/c/PhQ1_Gvjyzs/m/FCkTdrx1CAAJ
16:46:21 <dcf1> ggus: there's an --output-country-codes option to the scrape-geoip script in metrics-timeline
16:46:55 <dcf1> It's off by default because it creates too much noise, but if you activate it, it will give you the % +/- change in geoip entries for each country that was changed
16:47:37 <ggus> mmmh! i didn't know about that. i'm still not very familiar with our metrics tools
16:47:55 <dcf1> All the 'geoip and geoip6 databases updated' entries in the timeline are auto-generated by the scrape-geoip script
16:48:23 <dcf1> because at one point I thought that maybe sudden geoip changes could be responsible for sudden changes in user counts, but that hypothesis never really panned out
16:50:50 <arma2> and here arma is trying the hypothesis again
16:51:00 <arma2> i wish we had some new ideas in this space :)
16:51:34 <arma2> though in this case it is a huge geoip time gap
16:51:39 <arma2> not the usual monthly change
16:52:54 <arma2> though....hm. tor 0.4.5.9 got a new ipfire geoip update (june 2021)
16:53:52 <arma2> i guess the next step is to look at whether there is a correlation between tor version and user counts
16:54:34 * ggus checking r/ukraine
16:54:44 <arma2> i.e. if relays with older geoip dbs are predominantly claiming romania users
16:56:40 <cohosh> what does ooni use for geoip/asn data?
16:56:57 <arma2> hm. yet another angle to consider: if users in a given country spend more time with their tor browser running, our graphs will show that as more users. like, if the average person in the country moves from 2 hours of tor browser online per day to 4 hours, we'll show that the user count doubled.
16:57:07 <arma2> good question re ooni, i do not know
16:57:35 <arma2> but i think, at least as of long ago, they did the conversion at the client side, for privacy. so they probably wrestled with the maxmind license change too?
16:58:27 <cohosh> ok, we're getting to the end of the meeting
16:58:40 <cohosh> anything else for the last 2 mins?
16:58:46 <cohosh> i'll wait that long to close it
17:00:03 <cohosh> #endmeeting