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