16:59:41 #startmeeting anti-censorship meeting 16:59:41 Meeting started Thu Oct 24 16:59:41 2019 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:41 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:45 hi everyone! 16:59:48 hi 16:59:53 here's our meeting pad: https://pad.riseup.net/p/tor-censorship-2019-keep 17:00:00 hi! 17:00:40 let's get started with our gettor item 17:00:49 hmm, is this from last week? 17:01:14 no 17:01:19 i updated the roadmap 17:01:26 moved it into the gettor group 17:01:33 (instead of just in one of its projects) 17:02:04 hiro needs a roadmap that she can follow when working on stuff (the same with cohosh I guess) 17:02:35 thanks gaba 17:03:14 now that board is sync with trac (as from last week) 17:03:27 nice, thanks gaba! 17:03:48 we can close tickets in dip and tickets in trac when done 17:05:39 is there anything specific that we should be discussing wrt the roadmap? 17:06:11 mostly check that you agree with the prioritization of issues 17:07:17 looks good to me from here 17:07:53 ok 17:08:10 i see a duplicate of #27330 in the icebox and in next 17:08:19 hiro is going to connect soon and can also check 17:08:24 we can move to next topic 17:08:32 ahh, sorry. I will close one of those duplicates 17:08:33 cool \o/ 17:09:41 looks fine to me. i hope we can get to #31982 soon because it's user-facing 17:09:58 ...and i think it's more important than gettor's twitter bot 17:10:23 hi 17:10:30 sorry some issues with timezones 17:10:37 but i see that it's at the top of the backlog, so that's great :) 17:10:52 we can move it to next and get #27330 back into backlog 17:11:37 there are some tickets in next like #28232 that may be ready to close but we need to check it 17:11:43 hiro: https://dip.torproject.org/groups/torproject/anti-censorship/gettor-project/-/boards?scope=all&utf8=%E2%9C%93&state=opened 17:13:32 yes I can review the board and close what has been done 17:13:42 while also updating everything that I have been working on with its status 17:13:49 thanks hiro 17:14:25 no worries 17:15:00 cohosh: you are going to take also some tasks from gettor? 17:15:05 i can do that yeah 17:15:08 is there anything you need from hiro or phw or me about it? 17:15:12 i was just taking a look 17:15:29 and it looks like a lot of them require access to things i don't have access to 17:15:36 but i'll take some time and look through the code related ones 17:15:59 i'll reach out later with specific questions 17:16:00 can we have a 1:1 between hiro and you to transfer some access/knowledge here? 17:16:03 ok 17:16:20 that might be good, and a survival guide for how to update things 17:16:25 not sure if there's a ticket for that 17:16:34 and once you hear the survival guide, write it down for the next person :) 17:16:43 there's #31377 17:16:54 ah nice 17:17:01 #31377 is in the icebox 17:17:04 there's a spot for it on the wiki: https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam/GetTorSurvivalGuide 17:17:05 I have been documenting everything in the readme, but I have recently cleaned up all that virtualenv things 17:17:06 we can move it to the next thing we do 17:17:13 okay maybe i'll pick up that one first heh 17:17:36 so it can very well be rewritten... I can do that tomorrow so you have it 17:18:01 oh sure, i don't want to rush it if you have other things you need to move forward on 17:18:12 but that would be helpful for knowledge transfer 17:18:39 this happened these two last weeks while rebuilding the machine so that's why the readme became obsolete 17:18:40 thanks hiro! 17:18:45 ah okay 17:18:50 i think the survival guide is a great ticket to start with 17:20:05 phw what about I do the survival guide and cohosh could start to see where the code could be imporvd and add some more test coverage? 17:20:21 I haven't have time to test all those twisted callbacks 17:20:25 only unit testing 17:20:48 maybe some of those callbacks aren't even needed (these is baggage from how it was written) 17:20:49 sounds good to me 17:21:19 cohosh will need the survival guide to start and she can review it and ask questions to be sure everything needed is there 17:21:32 hiro: that works too. i figured cohosh would be a good person for the survival guide because she's new to gettor and it'll be easy to see what needs documenting, and how. 17:21:43 you, however, are a veteran :) 17:21:52 but that can also be a review and iteration on the survival guide as gaba said 17:22:03 yes, that works 17:22:41 yeah I think that works... so as I do the survival guide I can get all the needed access 17:23:10 sounds good 17:23:34 are we done with gettor? 17:24:07 this all sounds good to me 17:24:20 yes 17:24:41 ok, #29206 / turbotunnel is next 17:24:50 cohosh, can you take this item? 17:25:00 sure i guess this is a question i have for dcf 17:25:11 whether it makes sense to continue working on #29206 separately 17:25:28 or to start moving towards the work that's been done with turbo tunnel 17:25:59 I think it still makes sense to do #39306 unless you're not motivated to. 17:26:13 turbo tunnel in snowflake is at least a couple of months off, I reckon 17:26:23 ok, i'm happy to keep working on it 17:26:34 it will be good to have something in the meantime 17:26:58 and not even as a reusable library at that point, I intend the Snowflake integration to help inform requirements as to what would be needed for something like that 17:27:29 ok neat, i left some comments about that on the turbo tunnel post 17:27:32 sorry about #29207, I have overextended myself as usual 17:27:40 not sure if that's the best place for them 17:28:18 dcf1: it's ok about the reviews, how do you feel about me reaching out to phw for reviews on some of these larger changes 17:28:22 and how does phw feel about that as well? 17:28:51 the answer can also be that we should be ok with moving slowly 17:28:57 it's ok with me 17:29:57 cohosh: i'm fine with this. the first few iterations will probably take a while, and i'll have plenty of questions but it's a good opportunity for me to get more involved in the snowflake protocol 17:29:58 historically i have been a fan of modularity in pluggable transport components, and historically the modularity goals have shown us that putting together the puzzle pieces was harder than we first hoped 17:30:09 (like, remember back in the day when we thought it'd be cool to treat each PT as a pipe and you can layer them) 17:30:12 phw: awesome, thanks! 17:30:43 so, modularity looks appealing here too ("leave the reliability layer to turbo tunnel), and is probably more complex than it first seems. 17:31:32 arma2: that is the eventual goal, we're hoping having #29206 in snowflake in the meantime will help with some more urgent network health issues 17:31:53 like right now it takes a long time to recover from getting a bad snowflake 17:32:09 and it looks like your connection to the tor network is just failing 17:32:20 arma2: that was fog, no? i think there was a trac comment with a few "lessons learned" somewhere 17:32:37 keen. i would say that if you hadn't started on it, you should work toward turbo tunnel integration. but since there is a thing, and it kind of works, we can put something in place for users sooner rather than later, and also gain intuition and experience in the area, so sounds good 17:32:48 * cohosh learns about fog 17:32:48 phw: yes, fog was one piece of that 17:33:01 fog is spelled with the font that makes it clear it's f(g(x)) 17:33:24 lol good name 17:33:32 lol 17:33:48 * arma2 backs away so he doesn't sidetrack the meeting 17:33:59 ok that answers my question 17:34:53 cohosh: anything else wrt #29206? 17:34:57 or should we move on? 17:35:02 i'm good 17:35:04 thanks 17:35:43 the last discussion item is mine. i created some bridgedb usage metrics visualisations in #32135 and wanted to ask y'all, what other visualisations you would like to see 17:36:37 oh, and on a related note. i took a look at the request headers that bridgedb sees for moat requests. unfortunately, there's no "moat-ip", which meek-server is supposed to add afaik 17:36:56 so i wonder if our apache removes it somehow. somebody suspected so in an old ticket. 17:37:08 these look really nice! 17:37:15 the 'apache removes it' theory is a solid one 17:37:24 since i think we proxypass or something to bridgedb, right? 17:38:20 arma2: i'm not sure, the details are complex. sysrqb once did a comprehensive writeup of the setup and may know 17:38:47 ProxyPass /meek/ http://127.0.0.1:2000/ 17:38:47 ProxyPass /moat/ http://127.0.0.1:3881/moat/ 17:38:48 yes we do 17:39:01 see /etc/apache2/sites-enabled/bridges.torproject.org.conf 17:39:25 "moat-ip" is only for Google App Engine, so no surprise that it doesn't appear. 17:39:49 Azure CDN is supposed to always add X-Forwarded-For unless you specifically disable it https://docs.microsoft.com/en-us/azure/cdn/cdn-verizon-premium-rules-engine-reference-features#proxy-special-headers 17:40:36 i see. from bridgedb's PoV, x-forwarded-for is always 127.0.0.1 17:40:49 i'm not sure what happens with the header before bridgedb sees it 17:40:54 x-forwarded-for is supposed to be a chain though. The CDN's XFF should be in it too. 17:41:18 https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-server/useraddr.go#n10 17:42:18 #13171 is background on XFF and Meek-IP 17:42:42 that's useful, thanks 17:43:10 Meek-IP/Moat-IP only exists because at least at the time, App Engine didn't set XFF nor allow an app to set it. 17:43:49 hmm actually maybe I know what's going on. 17:43:52 ok, so the next step should be to figure out what happens to the XFF chain and why bridgedb only sees 127.0.0.1 17:43:58 Let me think and check with you after the meeting. 17:44:11 ok, thanks! 17:46:13 it would be good to see client addresses because i'd like to know how many moat requests come from tor. 17:46:30 recall that all our bot requests for the https distributor are coming over tor 17:47:49 all of the moat requests ought to come from tor, right? since tor browser ought to send them over tor 17:48:09 oh 17:48:14 no that is a very wrong statement. carry on. 17:49:11 shall we move on to our 'needs help with' sections? 17:50:25 hmm, i wonder if bridgedb has a separate distribution bucket for moat-over-tor. 17:50:30 like it does for https-over-tor. 17:52:00 ok, cohosh has #29206, #29207, #31310, #32131 17:52:09 dcf has #31890 17:52:25 i have #32105, #31874 17:52:29 still waiting for confirmation from sina 17:52:54 last week he replied "On top! Sorry for the late reply!" but nothing has changed on the ticket :/ 17:53:07 i suppose it's time for the weekly reminder 17:53:45 phw: can you take #31310 and #32131? 17:54:15 cohosh: yes 17:54:53 I'm doing #32131. 17:54:59 Commenting on it anyway. 17:55:00 ah thanks 17:55:23 * phw reverts the reviewer field of #32131 17:56:08 cohosh: do you have time to take a look at #32105 and #31874? 17:56:57 yep! 17:57:02 thanks 17:57:27 do we have a reviewer for #29206 and #29207? 17:57:43 it's me 17:58:04 but this is where I'm feeling a bit overwhelmed so if another wants to look too, it would be appreciated. 17:59:59 dcf1: i may be able to take one of these on. i'll coordinate with cohosh and let you know, ok? 18:00:35 ok 18:00:56 that should be it for today, just in time 18:01:04 thanks everyone 18:01:08 thanks! 18:01:09 #endmeeting