19:58:24 #startmeeting anti-censorship checkin 2019/02/14 19:58:24 Meeting started Thu Feb 14 19:58:24 2019 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:58:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:58:26 hello \o/ 19:58:30 hello everyone! 19:58:36 hello! 19:58:41 hey hey 19:58:43 our pad is at https://pad.riseup.net/p/tor-censorship-2019-keep 19:58:50 let's try to do weekly updates in the format described in the pad :-) 19:59:11 some vandals had changed some stuff in the pad which i think i have reverted now 19:59:25 please write date on your week label so we can clean it up before sending it out on the mailing list after the meeting :-) 20:00:10 do we have dcf, catalyst, and dgoulet here? 20:00:17 o/ 20:00:22 o/ 20:00:27 hi 20:00:50 cool with the meek helper webextension 20:01:36 hi 20:01:57 ok, do we start with thte roadmaps? 20:02:06 let's take announcements first? is the gottor one from this week? 20:02:17 oh, guess people can just read those. yeah, let's do roadmap! 20:02:33 ok, about snowflake the roadmap is here: https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0WeSY0B 20:02:49 is there anything in the 'in progress' column that has your name but you are not working on? 20:02:59 or is there anything snowflake related that you are working on that is not there? 20:03:11 okay, it looks like cohosh and i started with the 3 items in the backlog today. we want to discuss that after this 20:03:54 what about #28848 ? 20:04:05 I saw that you assigned actual points, does that mean is done? 20:04:11 ahf: Can you let me know what comes out of that discussion? Writing up those is on my list next. 20:04:12 i uploaded the draft today to the github repo 20:04:26 kat5: yeah, i'm going to do a summary for the email after the meeting too 20:04:43 kat5: the broker part is done, but i want to do a document for webrtc and the proxy too 20:04:53 Can you also send me a link to the draft you just mentioned? 20:04:53 i have some drafts there, but they are in a more sad state 20:05:07 https://github.com/ahf/snowflake-notes/blob/master/Broker.markdown 20:05:19 Okay. I just don't want to spend a lot of time writing about stuff that is no longer current. :-) 20:05:20 gaba: that is the draft ^^ i won't say it's done yet though 20:05:39 ok, does it need a review? 20:06:04 yeah, and there is some danglish in there that probably needs fixing 20:06:14 cohosh: are you up for coming with some feedback to what is there right now? 20:06:22 yeah definitely 20:06:25 maybe arma1 too 20:06:33 yes i will look at it 20:06:42 thanks 20:06:47 let's move the bug into needs_review 20:06:51 keep bugging me if i go lame :) 20:07:21 ok, what about #19001? Pili, do we have any update about that one? 20:07:47 hm, isn't that our "master" ticket for the goal for everything we do with this team the next couple of months? 20:07:50 no, I wanted to ask about that because we're still not sure how much we need to do from browser side 20:07:56 or is the browser team looking into things already? 20:08:11 we were under the impression that ahf was doing some work in this that we'd just need to integrate into our build at some point? 20:08:18 but we're not sure 20:08:33 I'm trying to find the discussion I had with GeKo about this but I've not had much luck with that yet 20:08:38 there are some tickets related to that one that we have in the roadmap for april 20:08:39 IMO #19001 is basically free after #25483 (Windows port) and #28672 (Android port) are done. 20:08:41 and he's out for the rest of this week and next week 20:08:53 yeah, i think that is the plan too. we work the next couple of months on getting snowflake "production" ready 20:08:56 yes 20:09:00 and then once we thin kthe browser team should get involved we prod them 20:09:06 sounds good to me ;) 20:09:08 they want us to prepare for marionette integration too 20:09:14 yes please 20:09:22 that's a quick win for us 20:09:28 ok, i'm moving that card to the icebox until we get the other stuff 20:09:28 yep 20:09:29 or it should be 20:09:36 gaba: sounds good 20:10:49 idem for #23888 , we have it for april and the webextension depends on that one. Is ux working on that? 20:10:50 remind me what the icebox means? it's things that is currently put on ice but have less priority than the backlog, right? 20:10:57 right 20:11:05 backlog is the column of stuff we need to get next 20:11:34 ye 20:11:50 kat5: when was it you were going on vacation? you wanted some feedback on report #2 20:12:10 kat5: i was planning on looking at it tomorrow morning if that helps in any way and try to give some feedback there 20:12:24 ahf: I updated my status. I did not get as much done this week as I wanted to. I'm away next week, but I will do some work while I'm gone. 20:12:38 oki, cool, so i can just give feedback on email? 20:12:40 I'll check in what I have before I leave tomorrow. 20:12:53 cool! 20:12:56 So if you can hold off a bit, that would be better. 20:13:04 Thanks. 20:13:13 Yes, email is fin. 20:13:15 fine 20:13:21 for the rest of stuff related to anti-censorship we have them in the network team roadmap filtered by s19 20:13:29 https://storm.torproject.org/shared/nNhTJhoWUB8lSnW3hMbS42BRf2ArVCNvyeCX3zBYTzN 20:14:14 there are labes to filter by bridgedb and by pluggable transport 20:14:14 ok, i'm pretty sure dgoulet is on the bridgedb ones this week 20:14:34 yes, #9316 and #29273 is what we have in progress for bridgedb 20:14:36 yes 20:14:36 both by dgoulet 20:14:40 * kat5 would like to ask a high-ish level question when that is convenient. 20:14:54 ok 20:15:20 Is that a go ahead? 20:15:20 we do not have anything for pluggable transport in 'in progress' or backlog 20:15:25 yes, go ahead 20:15:55 gaba: hm, don't think so. we did the goptlibext thing this week, which is related to some of the sponsor 8 stuff we did in december 20:15:56 So I know that there is thinking affoot about bringing bridge distribution by BridgeDB in line more wiht what the broker does. 20:16:24 actually yes, we have #28925 by catalyst 20:16:26 related to pt 20:16:30 gaba: #28940 20:16:40 kat5: yep? 20:16:41 Is the idea that at some point that will be all one thing, or will BridgeDB exist in || with the broker? Or don't we know yet? 20:16:58 we don't know yet is where we're at now 20:17:08 kat5: ah, good question. this is very much related to a lot of the discussions people had in brussels, but also related toe the protocol discussion we want to take after this roadmap stuff 20:17:34 Okay, cool. I've been wondering if including the older, lower priority BridgeDB tickets in the report is worth it. 20:17:40 gaba: oh, is "PT' here "PT things in Tor"? 20:17:41 right. it seems a bit silly to design two of them and have them stay separate. since they are so similar in what they try to do, and so similar in what improvements they will need, to be more robust, scale better, etc 20:17:45 oh, we do not have #28940 in the roadmap but is merge ready 20:17:59 gaba: ya, old s8 thing we didn't get around to do but is done this week 20:18:12 yes, i forgot to add those to the roadmap 20:18:16 ahh 20:19:37 should we go to 'needs help with' or do we have more roadmappy stuff? 20:19:48 yes 20:19:55 we can move on 20:20:05 pili: i see you have a help with to figure out what the browser team needs to do 20:20:12 yup 20:20:13 i'm not sure what the answer is there until we have something to give you 20:20:17 that's fine 20:20:18 like for example a marionette test node 20:20:23 I think that was answered already above 20:20:27 great! 20:20:32 thanks :) 20:21:04 kat5: re the NGO question: we have some discussions right now going on with figuring out some stuff around all of that, but it seems to be very much in the early stage. i think we should get you involved in those email discussions though when there are updates 20:21:18 actually, follow up question: any idea when you will have something to give us? :D 20:21:19 right now it has all happened over email 20:21:33 ahf: for the ngo thing, what is the best way for me to connect you to potential people who know about china, go to china, are in china, etc? 20:21:35 pili: would "before march 1st with a test instance of a marionette bridge" be OK? 20:21:38 ahf: is this RE the reachability tests? 20:21:50 ahf: that's more than ok :) 20:21:50 i was just making up a little list of people to start with. i could send mail to them and to you and cohosh 20:21:51 cohosh: i think so, yeah 20:21:59 you can even wait until after march 20:22:00 because i think that's different from the easy bridge set up thing? 20:22:06 ahf: Okay. That comes from a time when I was almost done with tickets, but then there were a bunch of new tickets added, and old tickets added, so it's lower priority for me anyway. 20:22:08 we'll be busy with releases until the end of Feb 20:22:17 ahf, cohosh: but i am hesitant to do the email introductions until we know we will follow up on them :) 20:22:30 arma1: did you get my email about the user inside GFW? 20:22:30 pili: oki, let's aim for getting it out of our hands a bit early so you guys can pick it up whenever you feel like it :-) 20:22:42 pili: it takes a bit to get marionette to build because they use some "interesting" libraries 20:22:54 arma1: on my todo list is to read the papers phw sent about reachability tests to come up with a definite plan 20:22:57 pili: i did! i think the answer there is yes, we should sign the person up to help us. it's not like our stuff is sekrit. 20:23:15 great! that's what I thought, but I wanted to double check 20:23:17 pili: can you send that mail on to ahf and cohosh too? so they have the contact? 20:23:22 yup, definitely 20:23:32 arma1: maybe include phw too? i don't know how much we can bother him with email for now though, but i guess he'll tell us if it becomes too much 20:23:34 pili: thanks! 20:23:51 pili: it is distantly possible that the person is the adversary, here to screw up our results. but we solve that by doing things several times and several ways, rather than by being scared of strangers 20:24:01 yup 20:24:08 pili: btw, thanks for doing the gsoc coordination! 20:24:11 sounds good to me :) 20:24:14 yw! 20:24:21 thanks for volunteering to mentor ;) 20:24:28 fingers crossed we get someone and they want to work on it 20:24:30 gaba: yes, this is a good question about phw. i was thinking to encourage him to know about kat5's report too. but maybe we should leave him alone until he officially starts. 20:24:32 I think it's a nice little project 20:24:39 :-) 20:24:46 hm, have we missed any "needs help with" on the pad? 20:25:02 (i was thinking of kat's report in particular, since it describes a roadmap that he will soon inherit) 20:25:20 arma1: It describes parts of the roadmap so far. 20:25:43 * kat5 worries that things are moving too quickly for me to keep up and non one has reviewed yet. 20:26:18 kat5: moving too quickly with the roadmap parts? 20:26:33 I think it is fine. I read your report and I only need to make comments. It is based on what we have and fine. 20:27:02 i have a quick question about the NGO bridge guide on kat5's weekly update 20:27:14 is this about distributing new bridges to NGOs? 20:27:19 or about helping NGOs set up bridges? 20:27:22 ahf: I write up tickets that not nailed down, then it gets nailed down and I don't necessarily notice that things have been updated. 20:27:46 kat5: nailed down? 20:28:05 cohosh: Phase 1 is about helping them set up their own bridges to give to their own people. 20:28:19 ok ty! 20:28:22 ideally we should be able to catch changes at this meeting, but i think the brussel meeting might have had a bit much offline activity so we are out of sync? 20:28:45 kat5 asked me to clarify a bunch of tickets i made from the meeting that were too vague 20:28:59 ahhh, yeah, i can understand that. some of them were very vague 20:29:00 ahf: Like a ticket is about "we should consider whether..." Then the consideration happens somewhere where I don't see it, so a decision is already made and my doc is out of date. 20:29:09 i think yawning was also concerned about one of them that had a very vague title 20:29:22 kat5: good point 20:29:51 hm, whenever we see that happen we should be sure to update the tickets and also feel free to ask on tickets. i can see how this quickly becomes a bit chaotic otherwise 20:29:55 cohosh: oh, something else to make sure your plan considers: how will we decide that obfs4 bridges are working for people? or aren't. like, imagine we get them a fresh obfs4 bridge, and somebody in china uses it, and says "my tor browser works but it's really slow". or "my tor browser worked for 30 minutes but then it stopped". in each case we will ask them for some further details. what details, and is there a way to automate that or make it 20:29:56 I think some of this will be fixed once people start reviewing. Which next week would be good for that. 20:30:06 kat5: yep 20:30:07 (oops, i wrote too much. let me know if my line got cut off.) 20:30:34 kat5: that's a really good point. should we try to consolidate + summarize all discussion on trac? 20:30:34 arma1: "a way to automate that or make it\0" 20:30:47 cohosh: "...or make it consistent or something." 20:31:15 yes, trac should be the place where we update what each issue is at 20:31:17 cohosh: I don't know. I don't know how people typically work with trac. 20:31:26 ^^^ 20:31:29 we are using trac as the source of all truth :) 20:31:34 cool :) 20:31:37 yeah, trac is our source of all truth 20:31:54 arma1: okay yeah, i was also wondering if we will be running client-side tests directly 20:32:02 or distributing bridges to users and having them report to us 20:32:38 cohosh: yep. probably a bit of both. depending on who our volunteers are and what their infrastructure is and etc. 20:32:41 i know dcf1 has also done reachability testing so if you have any advice i'd be happy to hear it :) 20:32:43 There was also a plan to insert work plans for all of the chunks of work into the report, but I don't know where those are going to come from. I don't know if devs usually write up plans for their work. 20:32:59 cool! many different tests is probably the best approach 20:33:07 kat5: hmm, i think a lot of have a plan for our next week, but not much more 20:33:10 kat5: sorry that I was planning on doing that and adding comments to your report. I'm behind on that. 20:33:13 some people might be more structured 20:33:38 this week i've spend more time on network team reviews than i had planned for example, but i think that is also an aftermath of the brussels meeting 20:33:48 Okay. I won't worry too much about that then. 20:33:50 cohosh: along those lines, we should maybe brainstorm a set of outputs that tor or tor browser could make for us that help us conclude the right thing. like, the long term plan is for tor browser to get good at knowing if stuff is working, but are there easy short term hacks we can put in to get that started. 20:34:22 gaba: is there some action items in this we need to have on the pad? 20:34:33 i don't think so 20:34:49 ack ack 20:35:36 do we move one with the protocol discusion? 20:35:39 arma1: yeah the longer term stuff i imagine phw will be alot of help with once he starts since he has done lots of reachability testing and knows the space very well 20:35:47 i think we are still in the NGO discussion 20:35:58 ahh, ok 20:36:00 ah sorry for the parallel convos 20:36:15 arma1: should we do an IRC session about the NGO thing? this sounds like it involves multiple teams but someone should lead it? 20:36:18 cohosh: no worries! 20:36:27 cohosh: i guess the other side to consider is: let's say *you* have a vps somewhere and you're trying tor + obfs4, and it "kinda works sometimes". what are the things you should look at to debug? 20:36:36 ahf: sounds great 20:37:11 yeah that's a good point, we should have some control connections from some non-censored area to compare perhaps 20:37:20 ahf: might be wise to get some of the actual users into that early, so we stop making up hypothetical things the users want or can do 20:37:27 agreed 20:37:37 but we should maybe figure out what we want first and make a list of what we want to do first 20:37:58 i've added an action item to the pad to do a meeting about this. let's do it before the next thursday meeting next week 20:38:13 ok. so (a) one round of figuring out what we want, and a list, (b) i introduce people to cohosh and ahf and phw, (c) meet 20:38:37 yeah, (a) is the thing we are doing on irc i think 20:38:48 or you want to do a/b/c at the same time for this? 20:38:55 a then b then c 20:39:17 right, but you want to have external parties part of this discussion within the next week? 20:39:41 no 20:39:55 good, so it's a pre-thing we are doing to that, but i agree with the a-then-b-then-c thing 20:40:02 ok 20:40:10 sorry to go back but I just saw the action about marionette. Does taht mean we need to work on #29272 before April? Right now we have it for April in the roadmap. 20:40:16 should we do the snowflake protocol discussion? 20:40:31 gaba: it's a small part of it i think. it's "just" getting a bridge up and running 20:40:36 gaba: then the browser team can experiment with it 20:40:46 gaba: right now experimenting with it is a lot of work if you need to setup the entire thing 20:40:53 ok 20:40:56 gaba: if we can provide the bridge to the browser team they can focus on the integration work 20:41:15 is that other ticket somewhere? 20:41:26 no, it should probably be a child ticket of #29272 20:41:55 ok 20:41:55 added an action item to the pad for that 20:42:34 should we go to the protocl thing? 20:43:06 sounds like yes 20:43:18 yes 20:43:18 cohosh and i continued a bit the snowflake protocol conversations we had in brussels 20:43:26 around how the current protocol works between the different components 20:43:31 and we did this: https://github.com/ahf/snowflake-notes/blob/master/Protocol.markdown 20:44:03 it's slightly related to that we have some things we might want to do in the future with the protocol and thus needs to make it more extensible 20:44:22 but also related to what kat5 mentioned earlier that maybe the "broker" design is useful for non-snowflake dynamic proxies too 20:44:37 which is out of scope for our current deliveries, but maybe we shuld keep it in mind 20:44:52 we also right now have no way of collecting "metrics" from proxies 20:44:57 and that is something we think we would like to do 20:45:30 some useful metrics could be "we can see that we have N clients from china reaching the broker and get the SDP", but we also see that "zero connections from china reach a proxy snowflake" 20:45:34 then we need to do something 20:46:12 one part that we were wondering aobut with the current design is whether the "poll" strategy is what we want? do we maybe want to have bi-directional communication line between proxies/broker and bridges/broker ? 20:46:19 such as for example a websocket 20:46:34 (cohosh please correct me if i forget something or miss some details here) 20:46:45 looks good so far! 20:47:12 and then instead of having these http polls we instead define a wire protocol between these components over a websocket 20:47:17 when you say "communication line between proxies/broker and bridges/broker", who is talking to who in this new line? 20:47:30 both can talk to each other 20:47:39 proxies<->broke and bridge<->broker 20:48:04 the client connection should remain what it is today where they get the ID and connect to the proxy via webrtc's datachannel 20:48:11 right the first step in deciding wehther to meld a bridgeDB-like thing or a broker is to get them talking the same protocol and figuring out what that protocol would look like 20:48:12 ah. in the current (old) design the bridge never talks to the broker 20:48:21 yeah we're mixing terms a bit here 20:48:26 yeah 20:48:40 with snowflake, the bridge is something only the snowflake proxies talk to directly 20:49:03 yep 20:49:26 yeah, right now the bridge is hardcoded in both the clients and the proxy as well, and we might want to make it possible for a client to pick a set of bridges instead of just having one (for scalability and availability i guess) 20:50:03 but if we want to look at a broker-like design for distributing, say, obfs4 bridges then the obfs4 bridges would be talking to the broker and would behave something like snowflake proxies from the perspective of the client and broker 20:50:09 hopefully that made sense ^^ 20:50:49 yeah, we might even want to see snowflake proxies differnetly: some are "browser based", some are "go based", some are "webextension browser based" 20:51:03 and some of these might be more stable than each other, which plays in with the priority of how we hand out snowflakes today 20:51:15 how we hand out snowflake proxies today* 20:51:54 dcf1: what is your thoughts to all of this? 20:52:05 nothing seems amiss in the discussion so far 20:52:17 cool 20:52:27 I'll note that currently snowflake proxies poll every 10 seconds, but with flash proxy we had many more proxies and we had them poll only every 10 minutes. 20:52:33 so, if cohosh and i started and doing a small websocket wire protocol between the components that would be OK? 20:52:36 Let me find a graph. 20:52:40 cool, thanks 20:53:33 https://people.torproject.org/~dcf/graphs/fp-num-proxies-201601.png 20:53:37 * ahf looks 20:53:59 With flash proxy we had (estimated) 2K-3K proxies active, and that was without trying much. Snowflake is opt-in so it doesn't necessarily transfer... 20:54:09 yeah 20:54:23 ...but I think you should design for the broker managing that order of magnitude of proxies 20:54:27 hm, okay, so this is useful to know also for when we think about how much load a snowflake broker can handle 20:54:30 yeah 20:54:33 agreed 20:54:49 or deciding whether to distribute the broker i guess 20:54:53 we also need to figure out some kind of way to have a broker hosted two places to distribute the load 20:54:56 ya 20:55:00 (two or more) 20:55:03 we have a section in the document about a possible broker--broker protocol 20:55:09 with not much in it yet 20:55:41 i think the part we have in our notes about giving proxies a long-term identity key (that is optional) is something we can wait with, but would be on the "nice to have" list 20:55:48 would allow us to later hand out more stable proxies 20:56:07 i like having in mind ways to make it more general and scale better, i also like taking the shortest path to an actual user using the tool, rather than building out the whole thorough version of the design before a user sees it 20:56:24 okay, but cool. it sounds like cohosh and i can begin to look at this next week then and look at how these protocols should look so we maybe can discuss that on thursday? 20:56:32 about distributing the broker, it's a good thing to think about, but IMO it's also far from being the most pressing thing. 20:56:41 dcf1: agreed 20:56:52 arma1: yeah 20:56:54 i think that's true for the bridge side too 20:56:56 Like, you would have to have a year of stupendous growth before distributing the broker became super important, I think. 20:57:02 https://people.torproject.org/~dcf/graphs/fp-facilitator-201601.png 20:57:03 nice to have a couple of options in mind for when you need more than one bridge, 20:57:04 another good thing about having a protocol and a spec is we can have protocol versions and make it easier to roll out new features 20:57:07 but let's fill up the first one 20:57:13 so to start with a minimal thing and then expand it later 20:57:18 Here's that same graph, but scaled to # of HTTP requests to the facilitator per second. 20:57:29 arma1: yeah, i think right now the interesting part is making it ready for that AND get some of the metrics we might want 20:57:39 Any web server can handle 10 requests/second if it's not doing anything too complicated. 20:57:49 yeah 20:57:54 But I do like the way you are taking the discussion, don't get me wrong. 20:58:09 i'm not that concerned about the broker being overloaded 20:58:11 true 20:58:17 i'm concerned when the broker is down and the person running it isn't around 20:58:21 and the system is unavailable 20:58:27 Yes, I agree, that is a more likely risk. 20:58:30 err, i'm *not* concerned 20:58:37 and the same with the bridge 20:58:50 i think 2 bridges in the beginning is fine, but we should make it such that we can easily expand that list if we need to later 20:59:33 okay, but cool! it sounds like we can make some progress with this over the next couple of days. should we go to the last item? i see we are at the one hour point now 20:59:38 but i think we can do the last one quickly 20:59:46 Hi! I need to go. I'm going to bring the discussion on pluggable transports to the meeting next weeek instead. 20:59:48 oh, it's gone from the list 20:59:51 ah, great 20:59:59 * gaba reminds that is 1 hour since we started. 21:00:04 yeah 21:00:22 okay, should we end the meeting for now and talk in #tor-dev over the next couple of days about the last discussion we just had? 21:00:37 sounds good 21:00:45 sounds good 21:00:51 i'll close the meetbot then, write a summary and post it to the ML 21:00:53 thanks all o/ 21:00:55 great 21:00:57 #endmeeting