17:01:13 <phw> #startmeeting anti-censorship weekly checkin 2019-05-16 17:01:13 <MeetBot> Meeting started Thu May 16 17:01:13 2019 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 17:01:27 <phw> our meeting pad is here: https://pad.riseup.net/p/tor-censorship-2019-keep 17:01:43 <phw> let's start with the announcement 17:01:47 * phw hands the mic to gaba 17:02:32 <gaba> about Tor meeting 17:02:46 <gaba> we need to decide how much time/space we will need for anti-censorship team 17:03:09 <gaba> I'm thinking one morning for roadmapping. And then other sessions open to the rest of Tor 17:03:15 <gaba> https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/DailyAgenda 17:03:34 <phw> fwiw, i don't need to have our roadmapping session "closed" 17:03:55 <ahf> i'd like to join in unless it collides with network team things 17:03:57 <gaba> yes, sorry for my bad wording 17:03:58 <phw> in fact, i would welcome other's opinion on what should be priorities 17:03:59 <gaba> not really closing 17:04:19 <gaba> I added it to the afternoon of the first day in the schedule (for 1 hour) but it can change. 17:04:36 <gaba> not really closed* 17:04:40 <phw> ok, gotcha 17:04:45 <gaba> we need to reserve time for a session on it 17:05:18 <phw> but yes, this sounds good to me. one morning for roadmapping and then another handful of sessions for more specific topics, such as gettor 17:05:26 <gaba> ok 17:05:51 <cohosh> +1 17:05:56 <ahf> sounds nice 17:06:11 <arma1> (hello world) 17:06:14 <gaba> We can move the roadmapping session around to an appropiate time in the first day and then you can participate in other's team roadmapping if you want. 17:06:56 <phw> oh, yes, i would like to participate in other roadmapping sessions 17:07:31 <gaba> ok 17:07:42 <phw> i also wonder if we feel like we need to adjust the roadmap again, after the more specific sessions 17:08:13 <phw> because that's when we will learn about things we didn't consider before 17:08:16 <ahf> it is my impression that often exciting ideas comes up during these meetings, after the roadmap sessions are over :-) 17:08:25 <gaba> we could do one more hour at the end of day 3 to readjust things 17:08:40 <phw> yes, an optional hour at the end of day 3 sounds good 17:10:00 <phw> ok, anything else wrt stockholm? 17:10:07 <arma1> (because doing your roadmap brainstorming before going to the other sessions will let you know what things to look for in the other sessions) 17:10:24 <gaba> nothing else from me 17:11:17 * phw ponders roadmapping sessions with exponentially increasing frequency 17:11:54 <phw> ok, let's move on to the discussion section. last week we retired 19 default bridges that were all inactive 17:12:24 <phw> team cymru offered to set up more but some people voiced concern that we shouldn't have one entity run this many bridges for us 17:12:43 <ahf> hm, i can setup one too, but they will be on the same /24 as two relays 17:12:59 <arma1> i think default bridges want to have 100mbit and plan to actually use it 17:13:35 <phw> arma1: you mentioned that some of your university contacts me be able to help, right? 17:13:40 <ahf> i always feel that we talk a lot about getting people to run relays, but not so often about bridges. do we give people t-shirts for running bridges and so on? 17:14:05 <arma1> the nonprofits that run exits could easily spin up some default bridges, but in the past they were concerned that since relays and bridges can't declare their family, nobody who runs an exit should ever run a bridge and vice versa. i don't think it is that clear, but the concern keeps floating around. 17:14:18 <arma1> ahf: nearly all bridges that people run will be useless 17:14:31 <arma1> because bridgedb can't stand up to china, and nobody else needs it 17:14:35 <arma1> (insert asterisks as needed) 17:15:00 <arma1> but yes, a tshirt for running a default bridge seems like a solid idea 17:15:11 <ahf> that doesn't make sense though? if we say all bridges should at least have 100 mbit/s it sounds like we have some capacity issue there and then also we don't want people to run bridges because they would be useless? 17:15:16 <ahf> that doesn't add up in my mind 17:15:28 <arma1> default bridges aren't useless 17:15:35 <arma1> the other ones have a high chance of being 17:15:37 <ahf> ah, right 17:16:23 <arma1> phw: yes, i can mail some profs and ask if they're interested to help out 17:16:28 <arma1> what is our..threat model for these things? 17:16:34 <arma1> that is, what security goals do we want for them 17:16:48 <arma1> do we need them run by people we know? for safety? or is that just for reliability that we might want that 17:17:22 <arma1> no need to answer that right now, but, we should think it through sometime 17:17:57 <phw> most importantly, i want someone who's responsive -- which may rule out all professors 17:18:04 <cohosh> have we made any special decision regarding default bridges in the past? 17:18:12 <arma1> true. they would pick a grad student. but grad students grad[uate]. 17:18:21 <phw> so we don't have this noisebridge problem again, where nobody actually runs the bridge 17:18:46 <arma1> the noisebridge people were responsive for the first few years 17:18:51 <arma1> what more can you ask for :) 17:19:04 <phw> hey, you gotta earn that t-shirt 17:19:13 <ahf> :-) 17:19:25 <arma1> cohosh: i think in the past, we mailed tor-assistants and got some volunteers from inside tor 17:20:08 <arma1> phw: so, you are suggesting a tshirt that you only earn at the three-year mark 17:20:24 * kat5 got weirdly frozen. Reading backlog. 17:21:25 <cohosh> swapping out default bridges every couple years seems okay, right? 17:22:02 <arma1> yes 17:22:09 <phw> i'll do a bit of brainstorming and add a list of criteria to our default bridge page: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges 17:22:15 <arma1> great 17:22:42 <phw> we may find some more volunteers in stockholm 17:23:27 <phw> next item on the discussion list is snowflake and ipv6 17:23:34 * phw hands the mic to whoever wants to take this 17:23:50 <ahf> arma1: do you wanna take it? 17:24:22 <arma1> sure 17:24:28 <arma1> so, the decoy routing people 17:24:32 <arma1> i talked to them at usenix security 17:24:41 <arma1> and they're pondering setting up a whole net block to essentially be obfs4 bridges 17:24:44 <arma1> or maybe to be snowflakes 17:24:55 <arma1> it's a research idea, so it will take a while to materialize, 17:25:05 <arma1> but this is our head start to think through whether our software would actually *work* in that situation, 17:25:12 <arma1> and if not, make some tickets now 17:25:13 <phw> (i hope netblock means /8 here) 17:25:46 <arma1> phw: it's complicated, but it could conceivably be a smaller block, but with actual users using the block too 17:25:53 <arma1> think "comcast does this with all their unassigned ip space" 17:26:28 <cohosh> i have a snowflake proxy on an ipv6 (and ipv4) address and clients are able to use the ipv6 address to connect 17:26:35 <cohosh> the broker afaik is only ipv4 17:27:02 <cohosh> so the proxies would ahve to be able to communicate with the broker 17:27:19 <arma1> ok. so if we get snowflakes on ipv6, they can volunteer as snowflakes, and tor browsers with ipv6 can reach them? sounds like we should get a v6 address for the broker? 17:27:33 <phw> i'm not sure i follow: isn't the idea of decoy routing is to secretly connect you to a destination that's masked by the decoy. why are they interested in running obfs4 or snowflakes? 17:27:34 <ahf> so #29258 could probably be resolved if the broker gets v6 support? 17:27:49 <cohosh> phw: i think this is the dark decoys thing we were talking about a few meetings back 17:27:58 <phw> oh, ok 17:28:00 <cohosh> and in the emails with the tapdance group 17:28:24 <cohosh> ahf: i believe so 17:28:53 <arma1> do..do tor browsers need to know which one they speak, to know which kind of ip to use to reach the broker? 17:28:54 <ahf> neat :o i couldn't get v6 to work on my weird qubes test setup 17:29:09 <cohosh> arma1: it should be automatically taken care of with STUN 17:29:18 <cohosh> and ICE 17:29:40 <arma1> i thought stun and ice were between the tor browser and the snowflake 17:29:44 <cohosh> the client gets candidates (that may be ipv4 and ipv6) and tries to connect to all of hem 17:30:27 <cohosh> arma1: right, through ICE (which uses STUN), the client gets a bunch of proxy candidates from the broker 17:30:35 <cohosh> and then tries to connect 17:30:49 <cohosh> this just works with what we have right now 17:30:50 <arma1> oh. so that's the protocol between the browser and the broker 17:30:55 <cohosh> for both ipv4 and ipv6 17:31:44 <cohosh> kind of, ICE is like a series of steps you go through, and one of the steps is to use a signaling channel (the broker) to actually get the candidates, which are candidate ways to connect to the remote proxy 17:31:57 <cohosh> (some please jump in if i'm getting these details wrong :)) 17:32:08 <arma1> i guess i'll add one more item to the list of things to consider then: is there a scalable way for us to periodically verify that ipv6-only tor browsers can still do snowflake? some sort of regression test 17:32:35 <arma1> i guess "have a bunch of them as actual users" might count. but maybe we can do something more controlled too 17:33:24 <cohosh> arma1: yeah, we should have more integration like tests with the entire system. i've been hacking on snowbox off and on to get more of this 17:33:39 <arma1> is there a ticket :) 17:33:40 <cohosh> but in general we don't have anything of this sort yet 17:33:51 <cohosh> #29259 17:33:58 <arma1> great 17:34:01 <cohosh> somewhat related ^ 17:35:02 * arma1 places the mic carefully back on the table (unless there is something more concrete we should do with this glimpse into our future where we will wish we had done something more now) 17:35:32 <phw> thanks arma1 17:36:01 <phw> next discussion item is kat5's 'help with' section 17:36:07 <kat5> Okay, 17:36:21 <kat5> So we are rapidly approaching end-of-kat5. 17:36:30 <ahf> :-( 17:36:33 <phw> :( 17:36:50 <kat5> We have a handful of tickets IN REVIEW. We need to decide which of these we feel comfortable marking DONE for the final report. 17:37:19 <gaba> We need to distribute tickets for review in this meeting. 17:37:20 <kat5> I don't know if we should look at them now, or if someone wants to go away and make decisions or what. 17:37:46 <kat5> Basically, I need to know next week what should be marked completed in the final report. 17:38:38 <cohosh> kat5: the list of these are the in_review tickets that are all under the Circumvention component in trac? 17:38:45 <gaba> https://trac.torproject.org/projects/tor/query?status=needs_review&component=%5ECircumvention&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority 17:38:47 <kat5> No, in the roadmap. 17:38:50 <gaba> are those the ones you are looking at? 17:38:56 <cohosh> oic okay 17:38:58 <kat5> https://storm.torproject.org/grain/MD4DhqFjAj7vyvfhFiF7vL/b/sandstorm/libreboard 17:39:31 <gaba> yes, we need to update the roadmap in this meeting. 17:39:58 <kat5> No, I've just been looking at the roadmap. 17:40:39 <gaba> phw, cohosh: maybe it makes sense to update the roadmap now. 17:41:01 <gaba> Take a look at the tickets filter by your name and see if the in progress and review are align to the things you are working on right now 17:41:08 <phw> kat5: i'm reasonably confident that 28655 wil be completed. i'll let you know otherwise. 17:41:32 <kat5> cool 17:41:41 <phw> i'll coordinate with hiro and let you know about the gettor tickets 17:41:44 <cohosh> #26348 will be done 17:42:01 <cohosh> in fact, it's in merge_ready in trac now so I'll move it 17:42:04 <hiro> sounds good 17:42:41 <kat5> What about #29863 17:42:55 <cohosh> ah, i sent an email to accounting@ and haven't heard back 17:43:06 <cohosh> it relies on getting a machine to monitor 3rd party services 17:43:23 <cohosh> so the block on that is either 1) hear back about the budget or 2) make snowflake-broker a TPA machine 17:43:28 <phw> gaba: yes, let's do that next 17:43:33 <cohosh> not sure when either of these will happen 17:43:50 <kat5> Okay, I'll plan to leave that as in progress unless I hear otherwise. 17:43:55 <cohosh> cool 17:44:00 <kat5> Thanks everyone! 17:44:19 <cohosh> thanks kat5! 17:45:10 <phw> ahf added #5304 to the discussion section. would be great to do that as part of s19 too, if it's trivial 17:46:39 <ahf> do we agree that it sounds "trivial"? to me it sounds like we need to propagate that value from the configs to the PT's and make the value available in gotptlib 17:46:53 <ahf> but i'm not sure what lead to this ticket popping up over the week? 17:46:58 <ahf> if it was some issue somebody ran into 17:47:07 <ahf> it's a 4 digit ticket, so it's old 17:48:41 <phw> i don't know how much work that would entail from tor's side 17:49:05 <arma1> nope, i just noticed it while reading the more recent ticket that links to it 17:49:14 <ahf> very little unless there is something unforseen around the spec work 17:50:36 <ahf> hm, no dcf here 17:50:41 <ahf> gonna hear him too what he thinks of this bug 17:51:10 <phw> sounds like a useful thing to have but i don't feel strongly either way. let's discuss it again next week when dcf is around? 17:51:17 <ahf> wfm 17:51:41 <phw> gaba: ok, the roadmap update. should we make sure that it's in sync with trac, or did you have anything else in mind when you said "update"? 17:52:33 <gaba> yes, that all the things in the 'in progress' is stuff you are working on 17:52:42 <gaba> the same with the 'in review' 17:53:22 <phw> my 'in progress' changes multiple times a day, but i try to keep it roughly in sync 17:53:43 <cohosh> hm i could do better at updating this 17:53:48 <gaba> in progress related to the roadmap work you are doing 17:53:59 <cohosh> ah so just things we roadmapped in january? 17:54:05 <cohosh> then it's accurate 17:54:12 <gaba> we do not have to update it every day but we can go through in the weekly meeting to be sure we are on track with the roadmap we agreed on 17:55:15 <phw> sounds good, thanks gaba 17:55:23 <phw> does anyone need reviews? 17:56:10 <cohosh> i have a PR for go-webrtc 17:56:12 <phw> i convinced cohosh to look at https://github.com/NullHypothesis/obfs4PortScan but would welcome another pair of eyes. it's ~200 lines of go code 17:57:42 <arlolra> I think dcf starting looking at the go-webrtc pull, but if not, I can take a look 17:58:01 <phw> dcf seems to have mentioned it in his pad report, yes 17:58:06 <cohosh> arlolra: it's very os-specific, so it probably needs some changes 17:58:09 <phw> the non-executable stack one, that is 17:58:50 <cohosh> i handled it with a linux.patch in tbb but we probably want to do something about it more generally 17:59:48 <phw> looks like that's it for this week 17:59:57 <phw> thanks everyone 17:59:59 <phw> #endmeeting