17:59:11 <phw> #startmeeting anti-censorship meeting
17:59:11 <MeetBot> Meeting started Thu Feb  6 17:59:11 2020 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:11 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:15 <phw> hi everyone
17:59:24 <phw> here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
17:59:51 <cohosh> hi!
18:00:33 <phw> cohosh: i added a discussion item about gettor's rate limit, if you think that's helpful
18:00:41 <cohosh> ah ok
18:00:59 <cohosh> i think the way to go here is a temporary fix and then an overhaul of how email processing works
18:01:19 <cohosh> but if anyone has insights into this i'd love to hear them
18:01:34 <cohosh> or if there's a history of gettor abuse
18:01:51 <phw> a temporary fix is fine. in the long term, we should figure out if gettor should rate limit at all and if so, how it should do it
18:02:29 <phw> i suspect that the cost of replying to an email is very low, so resource exhaustion isn't (much of) an issue
18:02:30 <cohosh> i was planning on doing some reading to see if there are lessons we can take from other automated email situations
18:02:51 <cohosh> yeah i'd like to remove the database interactions involved in receiving an email
18:02:59 <cohosh> that will cut down on resource consumption as well
18:03:06 <phw> that sounds good. off the top of my head i would mostly worry about somebody getting gettor blacklisted by major email providers
18:03:18 <cohosh> i don't think we need to save pending requests in database rather than just reply
18:03:32 <cohosh> yeah
18:03:41 <cohosh> and i don't think our current method handles that very well either
18:03:49 <cohosh> hm
18:04:08 <cohosh> ok i guess that's where to total limit helps
18:04:16 <hiro> the pending request are used in case something doesn't work
18:04:16 <phw> (we're talking about #33123, btw. thanks to whoever added this to the pad)
18:04:22 <hiro> because the service is a bit flaky
18:04:33 <cohosh> hiro: ah you're right that makes sense
18:04:35 <hiro> the db is used to track if the request was sent or not
18:04:44 <hiro> there are other ways how this could be accomplished
18:04:46 <hiro> ofc
18:04:56 <cohosh> ok
18:05:21 <hiro> yeah the whole "architecture" of gettor is rather old
18:05:22 <phw> yes, these proved useful in the past. i think pili was once pleasantly surprised to receive a gettor response once the outage was over
18:05:47 <cohosh> thanks for bringing up that use case
18:06:19 <cohosh> in terms of rate limiting, it would be useful to figure out what we're most worried about
18:06:56 <cohosh> having an total limit helps with prolonged spam but hurts if users happen to cross the limit and can no longer ever get gettor emails
18:07:23 <cohosh> whereas a rate limit is more for protecting our service from getting more requests than it can handle
18:07:46 <hiro> there is a quick fix if you save stats and kill the db and starts again every fixed amount of time
18:08:04 <hiro> like once a day or every 6 hours
18:08:53 <phw> i'm not a fan of a total limit. at least not for now. it protects us against a theoretical issue we haven't had yet, but it has already caused us actual pain
18:08:53 <cohosh> hiro: true, but if we don't want a total limit i'd rather just remove the entries like the current fix in #33123
18:09:17 <hiro> it's like having a temporary limit
18:09:32 <cohosh> phw: ok sounds good
18:10:19 <cohosh> alright i'll see if i can implement a temporary limit in the service
18:10:30 <cohosh> that seems cleaner than deleting the db externally every so often
18:11:39 <hiro> well my take was more along the line that the db needs to be killed every so often because we don't want it to grow too much (in disk space) and also it's purpose is temporary and finally we save the stats in csv and sends everything somewhere, ideally to metrics
18:11:57 <hiro> but sure your approach might be cleaner
18:13:24 <cohosh> if it's getting too big i think we should also fix that in the gettor service code
18:14:12 <cohosh> is there an open ticket for stats collection?
18:16:02 <hiro> not sure to be honest
18:16:10 <cohosh> ok we can take a look after the meeting
18:16:13 <phw> shall we 1) get rid of the total limit, 2) look into the possibility of a temporary rate limit, 3) and add other threats we can think of to #33123?
18:16:24 <cohosh> yes that sounds great
18:16:29 <hiro> I think it doesn't gets too big ... but it grows and it isn't useful was my take
18:16:35 <hiro> but yeah sure sounds good
18:16:43 <phw> ok, thanks cohosh and hiro
18:16:51 <phw> next item is tor browser and snowflake
18:17:44 <cohosh> i think sysrqb and the applications team had some questions here
18:17:56 <cohosh> they brought it up at their meeting this week
18:18:07 <cohosh> but i'm not sure if they are around today
18:18:29 <phw> sysrqb: ^
18:18:45 <phw> let's move on in the meanwhile and maybe have this discussion later if somebody from the applications team shows up
18:18:53 <cohosh> cool
18:19:25 <phw> next up is a team retrospective. we figured this would be useful to do once a month. the idea is to bring up what we think worked well, what didn't work well, and how we can improve
18:19:36 <phw> i can start
18:20:15 <phw> i like that we now have clear responsibilities about who takes care of what service and codebase. besides, it's now mostly more than one person, which is great, and makes us more resistant to failure
18:20:59 <phw> i also think that code review has been working well. it mostly happens on time and the review are of high quality as far as i can tell
18:21:51 <phw> what i think we should get better at is summarising our work to users. we should blog more, and be on top of blog comments
18:22:16 <phw> every so often, we should have a blog post on "what's new with bridgedb/snowflake/gettor"
18:22:31 <phw> and topics like "the state of using tor in china"
18:23:00 <stephw> i think that'd be great!
18:23:18 <cohosh> +1
18:23:22 <agix> +1
18:23:36 <phw> tor did an AMA on reddit a few years ago. i think that was great and it may be a good time to repeat that
18:23:41 <phw> anyway, that's it from my side
18:24:24 <cohosh> ok i can go next
18:25:35 <cohosh> i'll echo that the creation of and use of survival guides for various projects the anti-censorship team works on has been extremely helpful and makes me feel less anxious about something happening while someone is away
18:26:22 <cohosh> i've also been enjoying our interactions with volunteers and it's been cool to get more people at these meetings who are interested in picking up tickets or sharing what they are working on
18:27:36 <cohosh> right now what i feel the most out of the loop on is also what other groups have been doing on anti-censorship work
18:28:18 <cohosh> and i'd like to keep more up to date with recent studies, other tools, and concerns that come up from users of anti-censorship tools
18:28:56 <cohosh> done
18:29:07 <agix> cohosh: can i just quickly ask, what are these project survival guides you were mentioning?
18:29:37 <cohosh> https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#Servicesurvivalguides
18:29:59 <cohosh> agix: these are for running the various services/tools we work on
18:30:19 <slacktopus> <hellais> Sorry to drop in like that, but figured I would flag it during your meeting that we have made a release candidate of OONI Probe Desktop which supports checking the Tor network: https://github.com/ooni/probe-desktop/releases/tag/v3.0.0-rc.4
18:30:22 <cohosh> they have details like where they are deployed, where the log files are, how to update them, etc.
18:30:38 <agix> cohosh: great thank you!
18:30:50 <phw> hellais: woohoo, congrats and thanks!
18:30:59 <cohosh> nice hellais!
18:31:27 <phw> also, +1 to all of what you said cohosh
18:31:51 <phw> anyone else with thoughts on how we're doing and how we can do better?
18:33:09 <phw> ok, let's move on
18:33:49 <phw> speaking of ooni: karsten analysed ooni's "tor test" her: https://trac.torproject.org/projects/tor/ticket/32126#comment:1
18:34:22 <phw> the idea is to add these to tor metrics and karsten was wondering what exactly we would want on tor metrics. i added some feedback and please chime in as well if you have thoughts
18:35:35 <phw> some of these graphs are really interesting. for example the one for kazakhstan. most measurements reached tor's 20% bootstrapping stage only after 4 minutes, which is unusual
18:35:38 <slacktopus> <hellais> You may want to revisit that in light of the new Tor test
18:35:52 <phw> ...and raises the question if this is related to allot's DPI boxes
18:35:55 <slacktopus> <hellais> This is the specification for the new Tor test: https://github.com/ooni/spec/blob/master/nettests/ts-023-tor.md
18:36:25 <phw> thanks hellais
18:36:54 <slacktopus> <hellais> I think what we are measuring and how we are measuring it using the new tor test is going to be much more helpful to understand when and how tor breaks
18:37:10 <slacktopus> <hellais> For example we are able to tell you exactly which directory authorities are getting blocked and how
18:37:18 <slacktopus> <hellais> If they are reachable on the OR Port or the DIR Port
18:37:39 <slacktopus> <hellais> We also bootstrap an obfs4 client using the default tor browser bridges
18:37:45 <phw> yes, that's super helpful. simone did a great job at keeping me in the loop on that
18:38:04 * cohosh is impressed with how much data this gives us
18:38:31 <phw> oh, that reminds me. we just got a new default bridge, which you may want to add to ooni
18:38:39 <phw> i'll file a ticket
18:39:25 <phw> alrighty, let's move on!
18:40:06 <phw> we have three interesting links for this week. the magma guide (i think vasilis was involved in this) and two ietf drafts about proxy discovery, which seemed relevant
18:40:39 <phw> let's take a look at everyone's 'needs help with' section
18:41:44 <phw> i have two tickets (#30941 and #32860), cohosh has one for the browser team, cjb has one for the network team, and agix has some general question as far as i can tell
18:42:08 <cohosh> phw: i can review your tickets
18:42:12 <phw> thanks cohosh!
18:42:40 <slacktopus> <hellais> Speaking of that, we have a file which you can file a pull request for to update our testing list: https://github.com/ooni/sysadmin/blob/master/ansible/roles/probe-services/templates/tor_targets.json
18:43:02 <phw> perfect, thanks hellais. i'll add it to my todo list
18:43:23 <slacktopus> <hellais> The format should be pretty self explanatory, but it’s also documented in the above mentioned tor test spec
18:43:41 <phw> agix: you're wondering about the process of closing tickets and merging code?
18:44:18 <agix> yes exactly
18:44:34 <phw> this is a great question that we should probably have an answer for on our team page
18:45:27 <phw> basically, every patch must be reviewed by someone. if you have a patch for, say, bridgedb, you can make it available in whatever way you want. most people push a branch to github or gitlab. others sometimes upload the patch as textfile to the ticket
18:46:02 <phw> once you made your patch available, one of the maintainers of the respective project will review it and either sign off on it or walk you through revisions
18:46:25 <phw> once the patch looks good, the maintainer will merge it and deploy it. then we can close the ticket
18:47:03 <phw> that's a short summary. does that make sense? :)
18:47:54 <agix> ok i see, do i have to announce to someone that i have a patch ready to push, or do i just push it?
18:48:35 <phw> it's best to push the patch somewhere and then you can set the status of the ticket you're working on to "needs review"
18:48:54 <phw> ...and maybe ping whoever you would like to review your patch
18:49:13 <agix> great thanks for the intro
18:49:54 <phw> agix: anything else we can help with regarding processes?
18:50:25 <phw> maybe we can talk about bridgedb setup after the meeting?
18:50:29 <agix> i also ran into a few issues with setting up bridgedb, should i post my questions into the tor-dev channel or can i message you directly?
18:50:36 <agix> ok
18:50:45 <phw> let's talk about it in #tor-dev
18:51:03 <phw> so others can chime in and learn
18:51:34 <agix> alright thanks
18:51:54 <phw> also, thanks for your effort agix! it's really helpful to have someone try to set up bridgedb from scratch
18:52:19 <phw> anything else for today's meeting?
18:52:44 <agix> thanks for the opportunity! I really admire the Tor project and I always wanted to contribute
18:53:17 <phw> :)
18:53:28 <phw> ok, let's wrap it up for today. thanks everyone for attending
18:53:30 <phw> #endmeeting