20:01:47 #startmeeting anti-censorship weekly checkin 2019/04/18 20:01:47 Meeting started Thu Apr 18 20:01:47 2019 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:01:48 * arma1 is around 20:01:58 * catalyst is here 20:02:02 * kat5 is here 20:02:11 hi everyone 20:02:16 ok, let's start with our announcements 20:02:27 o/ 20:02:32 we now have a team wiki page: https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam 20:02:49 \o/ 20:03:09 let's try to add anything relevant to our work. we have a "useful links" sections for misc bits and pieces. 20:03:40 dcf1 created "survival guides" for snowflake machines, which are a great idea. we should have this for other systems too. 20:03:59 also, there's a table that lists maintainers for all of our services. 20:04:45 (i was unable to add our team page to the wiki's front page. there was no edit button.) 20:05:15 * gaba will add it 20:05:19 second announcement: we also have a mailing list now: https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team 20:05:52 it's public, fwiw 20:06:08 * phw should probably send an introductory email that summarises its use. 20:07:00 third announcement: thanks to gman999, we are now monitoring our anti-censorship infrastructure 20:07:30 atm this includes bridgedb, gettor, snowflake machines, and our default bridges. alerts go to cohosh and me. let me know if you want anything else monitored! 20:07:39 \o/ 20:07:50 That's fantastic. 20:08:24 ok, any questions/comments so far? if not, let's move on to the discussion section 20:08:35 (here's the pad if anyone doesn't have it: https://pad.riseup.net/p/tor-censorship-2019-keep ) 20:09:00 i think the first point is yours gaba, right? 20:09:37 yes, gettor 20:10:00 hiro can't be here today but she sent a status update of where she is in 20:10:24 i'm going to meet with her and phw tomorrow to go through all the tickets, sort them out, prioritize them and get them into our roadmap 20:10:36 she is going to be mantaining and working on gettor 20:10:54 kat5: hopefully this will work to include it in the report you are writing 20:11:08 Yes, I think it should help. 20:11:33 Hopefully some of the things in the current gettor list will become clearer. 20:11:48 yes, right now trac tickets of gettor are kind of messy 20:12:30 any question/comment about it? 20:13:07 sounds good 20:13:22 i moved the report writing talk for after this as it is kind of related 20:13:53 I think the main question is how to handle the completed work. 20:13:55 the question is, what do we write next? we were talking about writing a small third report about what has been done since first report 20:14:07 kat5: what do you mean? 20:14:07 Either include it in the current report or pull it out and make it separate. 20:14:12 yes 20:14:27 it could be included in the second report 20:15:02 If we do that, we can call it out as completed. 20:15:09 yes 20:15:12 any thoughts about this? 20:15:15 I'm just worried that if we pull it out, it will be really short. 20:15:16 arma1? 20:15:25 yes 20:15:59 * arma1 reads backlog 20:16:24 I also think it'll be more in context if we keep it all as one report, where some stuff is done, and some is future. 20:16:39 kat5: yes, agreed 20:16:40 kat5: that is something that can be done in may? 20:16:54 i'm ok with any permutation of our reporting plans 20:17:19 Yes. I think we'll just have to pick a cutoff, like mid-May, and then decide that what's done by then is what we'll consider done. 20:17:22 it might be a bit smart to call our last one the final one, so it's clear we meant it to be last. but we could probably even call it that retroactively. 20:17:26 ok, sounds good 20:17:51 anything else we may forgetting about this? 20:17:58 arma1: Yep, I'm already calling it final. 20:18:42 ok 20:18:50 gaba: I'm good. 20:18:53 ok 20:18:56 should we move on to the next item? 20:19:10 yes 20:19:21 gaba and i were wondering if we should have our meeting a bit sooner. i think it's hard for hiro and other non-NA folks to attend. 20:19:40 maybe 3 hours earlier? 20:19:44 sounds good to me 20:19:48 3 hours sounds good to me too 20:19:49 fine by me 20:20:12 great 20:20:12 ok, 17000 UTC 20:20:46 ok, next item: during our survey of the status of default bridges, we noticed that several seem gone for good: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges 20:21:15 it might be interesting to look at historical loads on the default bridges, as their numbers dwindled 20:21:18 paul pearce offered to start new ones at his new university and kpdyer was willing to transfer ownership of his broken fte bridges. 20:21:22 to realize just how overloaded they are 20:21:51 (an easy topic to outsource as a grad student research thing) 20:22:11 or if they are overloaded? is that known to be the case? 20:22:44 (FYI, I'm lurking if anyone has questions for me) 20:23:05 dcf1: right, exactly. i assume they are, because some years ago they were. who knows now. 20:23:20 i remember nima said his 100mbit obfs4 bridges were pretty consistently at 100mbit 20:23:37 my plan would be to ask paul pearce to set up new bridges if he has the time. 20:24:05 i'm not super excited to be running kpdyer's bridges. but if anyone is interested, the action is over in #28521 20:24:17 i think there's a good argument for retiring fte 20:25:11 we can probably get a bunch of folks to run fast bridges for us. one option would be the torservers.net partners, but historically people have been freaked out about running bridges and exits, since bridges can't be in families. that's why we went to university partners for the default bridges in the past. 20:25:40 when the time comes, let me know and i'll send some mails to various folks asking them if they could run a default bridge for us, and cc phw et al so they can follow up 20:26:13 i'll open a ticket in which we can discuss how to move forward with this. 20:26:21 we probably want some of these for some experiments on how bridges get enumerated too ^^ 20:26:40 (and perhaps they can later be used as default bridges?) 20:28:05 ln5 may also be able to share his experience with the bridges he's running 20:28:26 * gman999 listening 20:29:05 ok, anything else regarding default bridges? 20:29:28 limit per person and vm :) 20:30:47 that would be nice but we aren't exactly drowning in default bridges at the moment :) 20:31:04 understood. 20:31:13 but yes, let's try to get more, and have them run by new people. 20:31:43 not sure who wrote the next item on the discussion list? 20:31:58 oh, it was me 20:32:07 this is something we talked at last metrics monthly meeting 20:32:12 that was always the plan for that ticket, yeah 20:32:17 not much discussion but mostly about data collection 20:32:18 it's a good idea 20:32:23 ok 20:32:45 we still have a few things to do (like the websocket stuff ahf is working on) 20:33:02 that are prerequisites for making the needed changes in order to be able to collect metrics 20:33:11 ok 20:33:28 but there was also some discussion on geoip collection 20:33:45 here: #29734 20:34:03 talking with dcf1 we decided doing this for clients isn't a good idea right now 20:34:57 and dcf1 mentioned we might want to run this by more people w.r.t. proxy location data 20:35:29 yes, let's check with irl and karsten too on this 20:35:33 metrics and the safety board 20:35:38 okay cool 20:35:45 ok 20:35:50 thanks 20:35:55 we don't do any client metrics at all so far, so doing any would be a change for us 20:36:03 we've told users many times we don't do it 20:36:28 we could do it if it were really useful, but we'd have to be careful how we did it 20:36:33 irl: this is geoip data of clients, which i think bridges collect? 20:36:44 but yeah we don't think we need it for this 20:36:54 but geoip data of proxies might be useful 20:37:05 ah ok, we can collect that data if it's the bridge doing the aggregations 20:37:14 even the broker could do aggregations 20:37:29 \me cc'd irl and karsten on the ticket 20:37:37 the principle we like to use here is "source aggregation" where we put things into bins as soon as we see them so that sensitive data exists for as short a time as possible 20:38:16 * cohosh nods 20:38:22 can we add the discussion to that ticket? 20:38:37 yup, there's already some there so additional insight would be good 20:39:46 the next discussion point is dcf1's 20:40:10 See https://bugs.torproject.org/30125#comment:7 and leave a comment if there are specific statistics you'd like from the broker and proxy-go logs we have up to this point. 20:40:41 The summary of the situation is that we were keeping early-development level logs for longer than we should have been. 20:41:00 I'd like us to pick a deadline, say June 1, after which we delete the logs whether we done anything with them or not. 20:41:51 I want to make graphs of the number of proxy/client requests per hour, and graphs of the mean time between failure of the proxy-go instances, and that's all I think. 20:43:06 sounds good, i'll have a look at the ticket 20:43:24 sounds good to me 20:44:03 gaba: the next item is yours, right? 20:44:19 yes, just want to check that we are up to date on what we are working on in the roadmap 20:44:28 and is just replying to that question 20:45:06 and the next one is about code reviews, I do not remember if we said we were going to assing code reviews during this meeting. 20:45:35 let's do it! who needs reviews? :) 20:46:00 i think there's some discussion still worth having for #29863 20:46:08 requests for review have heretofore been in people's "Help with" section. 20:46:36 cohosh: re: 29863, I'm fine with going ahead with what's already been discussed (source IP filtering on prometheus) 20:46:43 ok 20:47:11 talking with anarcat it sounds like even with the IP filtering, the server where the graphs are located doesn't have strong authentication 20:47:24 Is that a public web page or something? 20:47:28 are we okay with that given that we're not collecting much 20:47:50 i'm not sure, they didn't say directly but my impression was a very simple .htaccess password? 20:48:08 Okay. We can talk further on the ticket if no one else has an opnion now. 20:48:12 cool 20:49:43 i started thinking about what statistics we want from bridgedb: https://trac.torproject.org/projects/tor/ticket/9316#comment:16 please comment in the ticket if you can think of anything else. 20:50:13 re statistics in general, my recommended guideline is: figure out what questions you want to be able to answer, and then shape your metrics collection around those. 20:50:38 the questions fall into general categories like "is it working" and "how much use does it get" 20:51:04 (also applicable to broker metrics brainstorming) 20:51:19 ah, good point 20:52:01 this way, you always know *why* you're collecting something, and you can periodically stop and think about whether you actually need that thing, and also whether that thing is the best way to answer the question 20:53:38 the comment i linked above has the underlying reasons for these statistics (though not phrased as questions) listed as sub-bullet points. 20:54:06 similar for the broker: https://trac.torproject.org/projects/tor/ticket/21315#comment:5 20:54:14 sounds good 20:55:09 does anyone else need help with something? 20:56:05 alright then, thanks everyone for attending 20:56:07 #endmeeting