20:00:16 #startmeeting anti-censorship checkin 2019/03/14 20:00:16 Meeting started Thu Mar 14 20:00:16 2019 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:20 hello everyone o/ 20:00:34 this weeks pad is at: https://pad.riseup.net/p/tor-censorship-2019-keep 20:00:45 i deleted some entries that it looked like hadn't been touched for a while 20:00:52 please remove old stuff and do updates 8) 20:01:23 hi :) 20:01:34 i think dgoulet, gaba, and dcf are all away for this meeting 20:01:44 oki! so very few people 20:01:47 so it will be pretty small 20:01:52 pili: hi! 20:02:07 catalyst, kat5: you here? 20:02:07 hey cohosh, how's it going? :) 20:02:17 Yep, just looking at the pad. 20:02:18 good :) 20:02:22 o/ 20:02:27 oops updating pad now 20:03:00 o/ 20:03:13 no worries, i think it will be a pretty short meeting today when we are so few 20:04:04 we can start with some good news! 20:04:14 the sysadmin team have set up everything for the gitlab instance for us 20:04:19 so now it's totally blocking on me 8) 20:04:25 ah yay \o/ 20:04:47 which is very good, so tomorrow morning i'm gonna start with trying to run the debian ansible stuff and see if anything magically appears on the website 20:05:02 i /hope/ that by next thursday we have an instance we can actually use 20:05:31 let's start by looking at snowflake roadmap 20:05:48 https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0WeSY0B 20:06:13 we have created some new child tickets over the week, we should probably get those in 20:06:56 right, I can take the action item on that 20:07:11 I think the two pads are related? or are they maintained separately? 20:07:11 should we move #25688 back to backlog/icebox and get the geoip one into needs review, no? 20:07:36 ahf: eh i'm actively working on that one even though i keep switching to other tasks 20:07:46 and yes, geoip should be in review 20:08:27 Which one is geoip? 20:08:40 kat5: it's not on the kanban board yet 20:08:41 i added 29736 20:08:48 cohosh: ah, makes sense 20:08:49 cohosh: okay, thanks. 20:08:50 #29734 20:09:02 i can put that on in the review pile? 20:09:11 we split up #29207 to smaller tasks 20:09:13 i guess it needs one more iteration from the review feedback 20:09:14 ahf: yup! 20:09:24 i need to address review feedback but it should be quick 20:10:01 okay, it has been added now 20:10:02 cool 20:10:12 i think that was it in terms of desync from real world? 20:10:41 yup and the websocket ticket you're working on 20:10:47 ya, added that one to in progress 20:10:51 ok cool 20:10:59 i think i need to go over some of the tickets and get points added 20:11:22 hm, i don't think anything have happened with bridgedb this week with dgoulet being AFK 20:12:07 i might try to look at what's needed to do the actual "release" 20:12:28 awesome 20:12:53 i think sysrqb is the goto person to hear about that 20:13:12 ok 20:13:40 hm, looks like the other roadmaps are good 20:14:00 i have the bridge probe test code in review 20:14:12 so if someone could take a look at that i'd appreciate it 20:14:34 i can take a look at that one. maybe it would be good to have dcf's eyes on it too? 20:14:35 meanwhile the next step is probably to get a vps in china to test it out for few days before we hand it off to NGO contacts 20:14:44 cool! 20:14:57 should we talk with arma about that? 20:15:00 yeah that would be great, it's basically just a few modifications to dcf's code from a previous experiment 20:15:12 yeah it would be good to update arma on the status 20:15:32 is there a procedure in TPO for getting VPS's for these things? So far I've just been doing stuff myself 20:16:05 i don't know :-o that was why i was thinking we could talk with roger about it 20:16:10 ah yeah okay 20:16:22 i have never had a need for a VPS around tor stuff before 20:16:31 the gitlab thing is the first sysadminy task i've tried 20:17:31 pili: it's a very good question you have asked... 20:17:44 it came from GeKo really :D 20:17:51 pili: i would say concentrate on snowflake 20:17:52 i really don't know the answer to it. i tried to write to John from RedJack last week and i got an email bounce back 20:17:59 which sort of tells me he is no longer working there 20:18:02 i'm a bit worried about marionette for a few things: 20:18:04 yeah, I had a quicklook at their github repo 20:18:11 doesn't seem like there's been any work there for a while 20:18:14 so i'd say, if we go the marionette way, we have to maintain it, which i don't think we have capacity for right now 20:18:20 so i think we should focus on snowflake 20:18:28 1) maintenance is a big question. it doesn't work well out of the box and we don't have time to spend on it on our roadmap right now 20:18:42 right, that was my follow up question, whether we'd want to fork it and take it on ourselves 20:18:51 2) we haven't fully looked at or assessed the method or implementation yet 20:19:08 yeah, #2 is actually the worst, #1 is just the here and now scary part 20:19:13 and I'd like to be sure it's in good shape before spending time working out deployment details that might change if we need to drastically restructure the code 20:19:28 makes sense 20:19:31 sounds perfectly reasonable to me :) 20:19:32 pili: yes exactly 20:19:54 I also have a question on the pad. 20:20:03 QUESTION: https://trac.torproject.org/projects/tor/ticket/25430 is in the bridgedb roadmap. Is there more to consider here than "moat fixes this"? 20:20:07 pili: if we decide to skip marionette for now does this mean that snowflake/browser integration work can begin earlier? 20:20:22 (Sorry..) 20:20:23 kat5: looking 20:20:40 ahf: I think so, it might even have started already (sorry, I've not followed that too closely) 20:20:54 let me see if I can find out where that is atm 20:21:19 kat5: hmm, good question 20:21:42 kat5: i'm also looking and wondering whether this is the case 20:22:04 i wonder if we can ask the user if this is still a problem 20:22:19 do we have moat usage stats by country? 20:23:01 ahf: ah yes, I remember now, I think we're still waiting on others to finish their bits first in #28672 and #25483 20:24:00 oof, if reproducible builds is a blocker for the applications team, maybe we should move the ticket up that looks at swapping out the webrtc dependency? 20:24:01 cohosh: i wonder if moat even passes the geoip in. this is a parallel situation to the snowflake stats. worth exploring imo. 20:24:25 i asked irl now in the other channel 20:24:34 and yes tor browser doesn't want to ship things that don't build reproducibly. 20:24:45 okay let me find that ticket... 20:24:51 cohosh: also, turkey is a good place for running our "what's up with obfs4" scripts once we have them 20:24:52 pili: ah, cool! thanks 20:25:10 because turkey was doing confusing censorship things last we heard 20:25:14 Re: my question, I guess I'll just hold off on documenting that ticket for a bit. 20:25:17 i think android might be easier fwiw 20:25:25 but windows is hard 20:25:32 pili: maybe one of those tickets are interesting to take for the browser team? 20:25:34 (harder as usual) 20:25:45 GeKo: pili: we were thinking of looking at alternatives for webrtc 20:25:50 so the anti-censorship team tries to do the windows one, the browser team takes the android one? i think the android is already in progress by HC? 20:26:01 that might also affect the reproducible build situation 20:26:09 but they are on the roadmap for april it seems 20:26:18 kat5: i think moat is a good answer to that ticket, yes. 20:26:53 arma1: Does that mean that someone should close the ticket and take it off the roadmap? 20:26:58 ahf, cohosh: do we have any monitoring for whether azure works in every situation? that is, if azure gets blocked in fooistan, then moat will stop working; how will we learn this? 20:27:03 kat5: yes 20:27:04 cohosh: yes, i think swapping out the webrtc licrary would help 20:27:16 fwiw, it's not webrtc per se that's the issue here 20:27:27 arma1: i don't think there is a plan/tasks for that (yet) 20:27:45 it's more a compiler problem 20:27:56 GeKo: yeah that was my understanding of it 20:28:06 ahf: so, yes, we could think about us looking at android if that would be helpfuk 20:28:10 *helpful 20:28:19 but the compiler issue was due to requirements specifically of the webrtc library we're using? 20:28:21 and coordinating with hc 20:28:40 GeKo: cool, that would be useful for us not to worry about 20:28:45 cohosh: i am inclined to say, yes 20:29:00 but it's likely more the whole chrome building system 20:29:07 arma1: (RE: moat) that is a good question and a good thing for us to take a look at :s i am not sure at all about the metrics situation of moat 20:29:23 ahf: deal then :) 20:29:34 \o/ 20:29:39 GeKo: ahf: do we want to move looking at library changes up in the roadmap then? 20:29:57 depends on how important windows bundles are 20:30:04 i guess we can do that in parallel with trying out the windows build 20:30:05 cohosh: we can also ignore windows for now :-/ 20:30:08 ok, ack 20:30:11 if the funder is happy with mobile instead 20:30:16 then maybe not 20:30:41 cool 20:30:49 cohosh: i think the windows component and our javascript parts are the two most risky parts of this whole project, and i think ditching the library means we end up looking at using a modified browser to do the webrtc code for us, no? 20:30:50 but, sure, having something for the majority of our users would be neat ;) 20:30:53 like with meek 20:31:06 where we spawn a headless browser that we control to do the webrtc code for us 20:31:13 ahf: not necessarily, but it was one of the options we were looking at 20:31:25 we have other libraries we could look at? 20:31:30 i think there was another library mentioned, let me dig it up 20:31:32 like firefox' implemention? 20:32:33 i think there's a ticket for it... 20:33:01 using a headless browser could work, but meek has now moved away from that 20:33:05 for being difficult to maintain 20:33:21 yeah 20:33:42 hm, can't find the ticket under the snowflake component 20:33:49 pion? 20:33:57 #28942 20:33:59 The tickets I've seen are to look at the pions go implementation and firefox. 20:34:13 ahf: that might be it 20:34:20 yeah i think so 20:34:51 hm, at that time it didn't support TURN 20:35:08 right, a lot of these implementations are still fairly new 20:36:30 okay if we aren't blocked on Windows, we can leave that for later in the roadmap 20:36:53 let's talk with gaba about this when she is around 20:37:04 the windows part 20:37:09 ok 20:37:22 #22718 is another alternate webrtc impl ticket 20:37:32 arma1: ah yes that's another one 20:37:39 hm, why is it closed 20:37:42 (abandoned in favor of pion one) 20:37:46 ok 20:37:54 "I'm going to close this because OpenWebRTC is no longer maintained." 20:38:01 oh, no longer maintained 20:38:04 that's fair 20:38:07 Doesn't support windows, as well. 20:38:11 if you blink, pion will become no longer maintained too 20:38:14 ah lol 20:38:27 webkit might support webrtc as well, which might be an option to take 20:38:34 yeah i think choosing something is still a bit risky as far as whether we will have to change again in the future 20:39:11 man they have their own campaign website https://www.webrtcinwebkit.org/ lol 20:39:22 with openwebrtc 20:39:24 okay, never mind 20:39:41 https://webkit.org/blog/7726/announcing-webrtc-and-media-capture/ 20:39:56 webkit is using libwebrtc it seems 20:41:49 one possibly really easy alternative to use is to use QtWebEngine (Qt interface to Blink/Chrome_shell), but it's a big dependency in terms of MB's 20:42:33 do we have more questions we need to look at today? 20:43:44 doesn't look like it 20:43:51 anything else? 20:44:28 i think we're good 20:44:35 Thanks everyone! 20:44:35 \o/ 20:44:36 #endmeeting