20:01:47 <phw> #startmeeting anti-censorship weekly checkin 2019/04/18
20:01:47 <MeetBot> 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 <MeetBot> 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 <phw> hi everyone
20:02:16 <phw> ok, let's start with our announcements
20:02:27 <gaba> o/
20:02:32 <phw> we now have a team wiki page: https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam
20:02:49 <cohosh> \o/
20:03:09 <phw> let's try to add anything relevant to our work.  we have a "useful links" sections for misc bits and pieces.
20:03:40 <phw> dcf1 created "survival guides" for snowflake machines, which are a great idea.  we should have this for other systems too.
20:03:59 <phw> also, there's a table that lists maintainers for all of our services.
20:04:45 <phw> (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 <phw> second announcement: we also have a mailing list now: https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
20:05:52 <phw> it's public, fwiw
20:06:08 * phw should probably send an introductory email that summarises its use.
20:07:00 <phw> third announcement: thanks to gman999, we are now monitoring our anti-censorship infrastructure
20:07:30 <phw> 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 <gaba> \o/
20:07:50 <kat5> That's fantastic.
20:08:24 <phw> ok, any questions/comments so far?  if not, let's move on to the discussion section
20:08:35 <phw> (here's the pad if anyone doesn't have it: https://pad.riseup.net/p/tor-censorship-2019-keep )
20:09:00 <phw> i think the first point is yours gaba, right?
20:09:37 <gaba> yes, gettor
20:10:00 <gaba> hiro can't be here today but she sent a status update of where she is in
20:10:24 <gaba> 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 <gaba> she is going to be mantaining and working on gettor
20:10:54 <gaba> kat5: hopefully this will work to include it in the report you are writing
20:11:08 <kat5> Yes, I think it should help.
20:11:33 <kat5> Hopefully some of the things in the current gettor list will become clearer.
20:11:48 <gaba> yes, right now trac tickets of gettor are kind of messy
20:12:30 <gaba> any question/comment about it?
20:13:07 <phw> sounds good
20:13:22 <gaba> i moved the report writing talk for after this as it is kind of related
20:13:53 <kat5> I think the main question is how to handle the completed work.
20:13:55 <gaba> 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 <gaba> kat5: what do you mean?
20:14:07 <kat5> Either include it in the current report or pull it out and make it separate.
20:14:12 <gaba> yes
20:14:27 <gaba> it could be included in the second report
20:15:02 <kat5> If we do that, we can call it out as completed.
20:15:09 <gaba> yes
20:15:12 <gaba> any thoughts about this?
20:15:15 <kat5> I'm just worried that if we pull it out, it will be really short.
20:15:16 <gaba> arma1?
20:15:25 <gaba> yes
20:15:59 * arma1 reads backlog
20:16:24 <kat5> 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 <phw> kat5: yes, agreed
20:16:40 <gaba> kat5: that is something that can be done in may?
20:16:54 <arma1> i'm ok with any permutation of our reporting plans
20:17:19 <kat5> 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 <arma1> 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 <gaba> ok, sounds good
20:17:51 <gaba> anything else we may forgetting about this?
20:17:58 <kat5> arma1: Yep, I'm already calling it final.
20:18:42 <arma1> ok
20:18:50 <kat5> gaba: I'm good.
20:18:53 <gaba> ok
20:18:56 <phw> should we move on to the next item?
20:19:10 <gaba> yes
20:19:21 <phw> 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 <gaba> maybe 3 hours earlier?
20:19:44 <cohosh> sounds good to me
20:19:48 <phw> 3 hours sounds good to me too
20:19:49 <kat5> fine by me
20:20:12 <phw> great
20:20:12 <gaba> ok, 17000 UTC
20:20:46 <phw> 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 <arma1> it might be interesting to look at historical loads on the default bridges, as their numbers dwindled
20:21:18 <phw> 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 <arma1> to realize just how overloaded they are
20:21:51 <arma1> (an easy topic to outsource as a grad student research thing)
20:22:11 <dcf1> or if they are overloaded? is that known to be the case?
20:22:44 <eighthave[m]> (FYI, I'm lurking if anyone has questions for me)
20:23:05 <arma1> dcf1: right, exactly. i assume they are, because some years ago they were. who knows now.
20:23:20 <arma1> i remember nima said his 100mbit obfs4 bridges were pretty consistently at 100mbit
20:23:37 <phw> my plan would be to ask paul pearce to set up new bridges if he has the time.
20:24:05 <phw> 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 <arma1> i think there's a good argument for retiring fte
20:25:11 <arma1> 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 <arma1> 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 <phw> i'll open a ticket in which we can discuss how to move forward with this.
20:26:21 <cohosh> we probably want some of these for some experiments on how bridges get enumerated too ^^
20:26:40 <cohosh> (and perhaps they can later be used as default bridges?)
20:28:05 <phw> ln5 may also be able to share his experience with the bridges he's running
20:28:26 * gman999 listening
20:29:05 <phw> ok, anything else regarding default bridges?
20:29:28 <gman999> limit per person and vm :)
20:30:47 <phw> that would be nice but we aren't exactly drowning in default bridges at the moment :)
20:31:04 <gman999> understood.
20:31:13 <phw> but yes, let's try to get more, and have them run by new people.
20:31:43 <phw> not sure who wrote the next item on the discussion list?
20:31:58 <gaba> oh, it was me
20:32:07 <gaba> this is something we talked at last metrics monthly meeting
20:32:12 <cohosh> that was always the plan for that ticket, yeah
20:32:17 <gaba> not much discussion but mostly about data collection
20:32:18 <cohosh> it's a good idea
20:32:23 <gaba> ok
20:32:45 <cohosh> we still have a few things to do (like the websocket stuff ahf is working on)
20:33:02 <cohosh> that are prerequisites for making the needed changes in order to be able to collect metrics
20:33:11 <gaba> ok
20:33:28 <cohosh> but there was also some discussion on geoip collection
20:33:45 <cohosh> here: #29734
20:34:03 <cohosh> talking with dcf1 we decided doing this for clients isn't a good idea right now
20:34:57 <cohosh> and dcf1 mentioned we might want to run this by more people w.r.t. proxy location data
20:35:29 <gaba> yes, let's check with irl and karsten too on this
20:35:33 <cohosh> metrics and the safety board
20:35:38 <cohosh> okay cool
20:35:45 <gaba> ok
20:35:50 <gaba> thanks
20:35:55 <irl> we don't do any client metrics at all so far, so doing any would be a change for us
20:36:03 <irl> we've told users many times we don't do it
20:36:28 <irl> we could do it if it were really useful, but we'd have to be careful how we did it
20:36:33 <cohosh> irl: this is geoip data of clients, which i think bridges collect?
20:36:44 <cohosh> but yeah we don't think we need it for this
20:36:54 <cohosh> but geoip data of proxies might be useful
20:37:05 <irl> ah ok, we can collect that data if it's the bridge doing the aggregations
20:37:14 <irl> even the broker could do aggregations
20:37:29 <cohosh> \me cc'd irl and karsten on the ticket
20:37:37 <irl> 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 <gaba> can we add the discussion to that ticket?
20:38:37 <cohosh> yup, there's already some there so additional insight would be good
20:39:46 <phw> the next discussion point is dcf1's
20:40:10 <dcf1> 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 <dcf1> The summary of the situation is that we were keeping early-development  level logs for longer than we should have been.
20:41:00 <dcf1> 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 <dcf1> 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 <phw> sounds good, i'll have a look at the ticket
20:43:24 <cohosh> sounds good to me
20:44:03 <phw> gaba: the next item is yours, right?
20:44:19 <gaba> yes, just want to check that we are up to date on what we are working on in the roadmap
20:44:28 <gaba> and is just replying to that question
20:45:06 <gaba> 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 <phw> let's do it!  who needs reviews? :)
20:46:00 <cohosh> i think there's some discussion still worth having for #29863
20:46:08 <dcf1> requests for review have heretofore been in people's "Help with" section.
20:46:36 <dcf1> cohosh: re: 29863, I'm fine with going ahead with what's already been discussed (source IP filtering on prometheus)
20:46:43 <cohosh> ok
20:47:11 <cohosh> 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 <dcf1> Is that a public web page or something?
20:47:28 <cohosh> are we okay with that given that we're not collecting much
20:47:50 <cohosh> i'm not sure, they didn't say directly but my impression was a very simple .htaccess password?
20:48:08 <dcf1> Okay. We can talk further on the ticket if no one else has an opnion now.
20:48:12 <cohosh> cool
20:49:43 <phw> 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 <arma1> 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 <arma1> the questions fall into general categories like "is it working" and "how much use does it get"
20:51:04 <arma1> (also applicable to broker metrics brainstorming)
20:51:19 <phw> ah, good point
20:52:01 <arma1> 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 <phw> 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 <cohosh> similar for the broker: https://trac.torproject.org/projects/tor/ticket/21315#comment:5
20:54:14 <arma1> sounds good
20:55:09 <phw> does anyone else need help with something?
20:56:05 <phw> alright then, thanks everyone for attending
20:56:07 <phw> #endmeeting