17:59:11 #startmeeting anti-censorship meeting 17:59:11 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:15 hi everyone 17:59:24 here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 17:59:51 hi! 18:00:33 cohosh: i added a discussion item about gettor's rate limit, if you think that's helpful 18:00:41 ah ok 18:00:59 i think the way to go here is a temporary fix and then an overhaul of how email processing works 18:01:19 but if anyone has insights into this i'd love to hear them 18:01:34 or if there's a history of gettor abuse 18:01:51 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 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 i was planning on doing some reading to see if there are lessons we can take from other automated email situations 18:02:51 yeah i'd like to remove the database interactions involved in receiving an email 18:02:59 that will cut down on resource consumption as well 18:03:06 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 i don't think we need to save pending requests in database rather than just reply 18:03:32 yeah 18:03:41 and i don't think our current method handles that very well either 18:03:49 hm 18:04:08 ok i guess that's where to total limit helps 18:04:16 the pending request are used in case something doesn't work 18:04:16 (we're talking about #33123, btw. thanks to whoever added this to the pad) 18:04:22 because the service is a bit flaky 18:04:33 hiro: ah you're right that makes sense 18:04:35 the db is used to track if the request was sent or not 18:04:44 there are other ways how this could be accomplished 18:04:46 ofc 18:04:56 ok 18:05:21 yeah the whole "architecture" of gettor is rather old 18:05:22 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 thanks for bringing up that use case 18:06:19 in terms of rate limiting, it would be useful to figure out what we're most worried about 18:06:56 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 whereas a rate limit is more for protecting our service from getting more requests than it can handle 18:07:46 there is a quick fix if you save stats and kill the db and starts again every fixed amount of time 18:08:04 like once a day or every 6 hours 18:08:53 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 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 it's like having a temporary limit 18:09:32 phw: ok sounds good 18:10:19 alright i'll see if i can implement a temporary limit in the service 18:10:30 that seems cleaner than deleting the db externally every so often 18:11:39 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 but sure your approach might be cleaner 18:13:24 if it's getting too big i think we should also fix that in the gettor service code 18:14:12 is there an open ticket for stats collection? 18:16:02 not sure to be honest 18:16:10 ok we can take a look after the meeting 18:16:13 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 yes that sounds great 18:16:29 I think it doesn't gets too big ... but it grows and it isn't useful was my take 18:16:35 but yeah sure sounds good 18:16:43 ok, thanks cohosh and hiro 18:16:51 next item is tor browser and snowflake 18:17:44 i think sysrqb and the applications team had some questions here 18:17:56 they brought it up at their meeting this week 18:18:07 but i'm not sure if they are around today 18:18:29 sysrqb: ^ 18:18:45 let's move on in the meanwhile and maybe have this discussion later if somebody from the applications team shows up 18:18:53 cool 18:19:25 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 i can start 18:20:15 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 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 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 every so often, we should have a blog post on "what's new with bridgedb/snowflake/gettor" 18:22:31 and topics like "the state of using tor in china" 18:23:00 i think that'd be great! 18:23:18 +1 18:23:22 +1 18:23:36 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 anyway, that's it from my side 18:24:24 ok i can go next 18:25:35 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 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 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 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 done 18:29:07 cohosh: can i just quickly ask, what are these project survival guides you were mentioning? 18:29:37 https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#Servicesurvivalguides 18:29:59 agix: these are for running the various services/tools we work on 18:30:19 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 they have details like where they are deployed, where the log files are, how to update them, etc. 18:30:38 cohosh: great thank you! 18:30:50 hellais: woohoo, congrats and thanks! 18:30:59 nice hellais! 18:31:27 also, +1 to all of what you said cohosh 18:31:51 anyone else with thoughts on how we're doing and how we can do better? 18:33:09 ok, let's move on 18:33:49 speaking of ooni: karsten analysed ooni's "tor test" her: https://trac.torproject.org/projects/tor/ticket/32126#comment:1 18:34:22 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 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 You may want to revisit that in light of the new Tor test 18:35:52 ...and raises the question if this is related to allot's DPI boxes 18:35:55 This is the specification for the new Tor test: https://github.com/ooni/spec/blob/master/nettests/ts-023-tor.md 18:36:25 thanks hellais 18:36:54 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 For example we are able to tell you exactly which directory authorities are getting blocked and how 18:37:18 If they are reachable on the OR Port or the DIR Port 18:37:39 We also bootstrap an obfs4 client using the default tor browser bridges 18:37:45 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 oh, that reminds me. we just got a new default bridge, which you may want to add to ooni 18:38:39 i'll file a ticket 18:39:25 alrighty, let's move on! 18:40:06 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 let's take a look at everyone's 'needs help with' section 18:41:44 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 phw: i can review your tickets 18:42:12 thanks cohosh! 18:42:40 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 perfect, thanks hellais. i'll add it to my todo list 18:43:23 The format should be pretty self explanatory, but it’s also documented in the above mentioned tor test spec 18:43:41 agix: you're wondering about the process of closing tickets and merging code? 18:44:18 yes exactly 18:44:34 this is a great question that we should probably have an answer for on our team page 18:45:27 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 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 once the patch looks good, the maintainer will merge it and deploy it. then we can close the ticket 18:47:03 that's a short summary. does that make sense? :) 18:47:54 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 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 ...and maybe ping whoever you would like to review your patch 18:49:13 great thanks for the intro 18:49:54 agix: anything else we can help with regarding processes? 18:50:25 maybe we can talk about bridgedb setup after the meeting? 18:50:29 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 ok 18:50:45 let's talk about it in #tor-dev 18:51:03 so others can chime in and learn 18:51:34 alright thanks 18:51:54 also, thanks for your effort agix! it's really helpful to have someone try to set up bridgedb from scratch 18:52:19 anything else for today's meeting? 18:52:44 thanks for the opportunity! I really admire the Tor project and I always wanted to contribute 18:53:17 :) 18:53:28 ok, let's wrap it up for today. thanks everyone for attending 18:53:30 #endmeeting