16:59:54 <phw> #startmeeting anti-censorship weekly checkin 2019-05-30
16:59:54 <MeetBot> Meeting started Thu May 30 16:59:54 2019 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:54 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:57 <phw> hi everyone o/
17:00:08 <kat5> Hello!
17:00:14 <cohosh> hi!
17:00:49 <phw> fyi, here's our meeting pad: https://pad.riseup.net/p/tor-censorship-2019-keep
17:01:07 <phw> a brief announcement: as part of our sponsor 28 work, we will revise our PT spec
17:01:36 <phw> that means first trying to figure out what the shortcomings are.  i'll be emailing people and asking them about their experience and what they would improve
17:01:58 <phw> once we have a good idea of the shortcomings, we will revise the spec
17:02:25 <phw> we are at step 0 for this, but it's an exciting task, so i figured it's worth an announcement
17:03:38 <phw> i'll do the actions before our discussion section: it would help me a lot if you added the highlights of your may to the following pad: https://pad.riseup.net/p/P7hQ98M9fI0ck2SwKJYd
17:03:57 <phw> i will then turn the pad into our monthly report for may
17:05:05 <phw> next up is our discussion section.  ahf added a point but he's not here.  i'm also not sure if the point is from last week or not
17:05:28 <gaba> hi!
17:05:29 <cohosh> is gaba here?
17:05:38 <phw> hi gaba!
17:05:41 <cohosh> hi o/
17:05:45 <gaba> i/
17:05:47 <gaba> o/
17:06:28 * phw wonders if he should continue his monologue
17:06:44 <catalyst> o/
17:07:03 <cohosh> gaba: did you have something for ahf's discussion point?
17:07:12 <gaba> phw:let's skip the discussion from ahf until he is here
17:07:37 <gaba> no, we want ahf to be a liason for anything that may need to be worked on network-team side
17:07:54 <phw> yes, we can discuss ahf's point next week if it's still relevant.  let's all think about tickets that involve the network team.
17:08:04 <phw> the next two points are cohosh's.
17:08:06 * phw hands the mic
17:08:10 <gaba> oh, catalyst is here :)
17:08:13 <arma5> phw: speaking of monthly reports, we don't actually have a contract with georgetown yet, but when we do, i expect it will include us writing up monthly summaries of progress toward race
17:08:22 <gaba> catalyst: do you have any point related to line 36 on the pad
17:08:37 <phw> arma5: ok, good to know
17:08:55 <cohosh> so the first point is about near and future changes to snowflake
17:09:28 <catalyst> gaba: i think right now mostly #30639
17:09:29 <cohosh> we want to add some kind of simple sequencing layer between the client and proxies
17:10:07 <cohosh> but this change would require all clients and all proxies to upgrade in order to be able to talk to each other effectively
17:10:24 <cohosh> there's not currently a versioning mechanism (we could add it for the future though)
17:10:32 <cohosh> and the question is about how to handle this
17:11:03 <dcf1> cohosh: the way I envision it, proxies don't need to know the sequencing tlayer, it's only the client and server that need to be aware of it. (End-to-end principle.) So manybe not all proxies have to upgrade.
17:11:20 <dcf1> But in any case the question still stands with regard to client upgrades.
17:11:34 <cohosh> dcf1: ah that simplifies it a bit
17:12:05 <cohosh> we could probably make things backwards compatable but it would be messy
17:12:22 <cohosh> and maybe we'd want to eventually discontinue support of really old versions anyway
17:12:47 <dcf1> i have some thoughts but not gathered and probably not best to dredge them up off the cuff in the meeting
17:12:59 <cohosh> that's fair, there's no immediate rush
17:13:00 <phw> do we have a ticket for this?
17:13:29 <cohosh> we could make a ticket or just put it in ticket #25429 or #29206
17:13:59 <cohosh> when they are closer to being in review
17:14:21 <dcf1> the same concern comes up with e.g. the AMP cache rendezvous, it would be nice to use a different broker protocol (that doesn't rely on HTTP status codes), but it creates a dilemma betwen breaking backwards compatibility or increasing complexity.
17:14:22 <cohosh> i'll probably ask for an early incrememntal review anyway
17:14:39 <cohosh> yup good point
17:15:00 <cohosh> if we ever change how any of the snowflake pieces talk to each other this will come up
17:15:07 <dcf1> my short response is, I think there are some graceful ways we can make the upgrade, and also at this point I think the few users are devoted enough that breaking compatibility is feasible.
17:15:34 <cohosh> cool
17:15:34 <arma5> seems like backward compatibility is not so big a deal with so few users. yeah.
17:15:36 <dcf1> I think what you're getting at is we don't want to be maintaining v1, v2, v3 of the protocol, and I agree.
17:16:08 * Samdney arrives to the meeting and is reading backlog ....
17:17:01 <cohosh> okay we can continue talking about this later, i mostly wanted to bring it up early so we could think about it a bit
17:17:46 <cohosh> the next point is about the obfs4 probe tests we've been doing
17:18:04 <cohosh> the point of these tests was to see if obfs4 was being blocked at the protocol level or if it was mostly bridge enumeration
17:18:34 <cohosh> i think we've pretty much answered that as well as we can with our current tests, but i wanted a quick okay before i stopped running them
17:19:10 <kat5> What is the answer?
17:19:27 <phw> i think it's fine to stop the test.  it would be great if our test machinery was automated enough to start it again quickly, if the need comes up.
17:19:45 <cohosh> kat5: looks like there isn't anything about obfs4 that's causing them to be blocked right now, our private bridges remained reachable
17:19:55 <kat5> Cool.
17:20:13 <arma5> do we understand any more about the active probing triggering
17:20:18 <cohosh> there are a few more interesting tests we can run now, like seeing how quickly bridges get blocked after being added to bridgedbb and which partitions
17:20:21 <arma5> like, are we not causing active probing?
17:20:50 <cohosh> arma5: i have some .pcap files I can check, but i wasn't specifically looking for it
17:21:09 <cohosh> it might be worthwile to set up a new active probing test like the one-off ones phw was doing?
17:21:40 <arma5> i think the research question "what's up with active probing of obfs4, how come there are rumors that obfs4 doesn't trigger probing anymore" is
17:21:43 <arma5> important
17:22:03 <arma5> it's certainly something josh will want to hear about
17:22:14 <arma5> and, this is the right time to learn the answer, since china will change again eventually and the window will be past
17:22:23 <phw> i'm in touch with a research group who seems to be studying active probing -- at least for vanilla tor.  i'll try to get them to answer this question for us.
17:22:42 <arma5> keen
17:22:48 <cohosh> \o/
17:23:06 <cohosh> that's it for me for discussion :)
17:24:28 <phw> cohosh: do you mind creating a new ticket for the snowflake versioning/backwards compatibility discussion? it would be great to have yours and dcf1's thoughts in one place.
17:24:41 <cohosh> okay will do
17:24:44 <phw> thanks!
17:25:29 <phw> ok, who needs code review or help with anything?
17:25:56 <kat5> I just need you to sign off on the report. :-)
17:26:01 <phw> i came up with a short list of criteria for our default bridges: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges#Addingnewdefaultbridges let me know if i missed anything
17:26:10 <phw> kat5: yes, i'll get to it right after the meeting!
17:26:15 <gaba> catalyst was bringing #30639 . I think is mostly to see if this fit into the RACE work, no?
17:26:16 <kat5> tyvm
17:26:45 <catalyst> gaba: which sponsor is RACE?
17:27:26 <gaba> the new one on PT work
17:27:35 <gaba> s28 following some of the work from s19
17:27:43 <cohosh> phw: i'll take a look at the wiki after this meeting
17:27:55 <catalyst> does s28 cover improving bootstrap reporting?
17:27:58 <phw> gaba: hmm, i'm not sure if i see the link to race...?
17:28:03 <catalyst> or is it more tightly scoped to PTs?
17:28:34 <gaba> yes
17:29:19 <phw> cohosh: thanks.  btw, there's a broader discussion on if bridge ops should also run exits.  some people think "yes", others think "no".  i suppose we should come to some kind of agreement on this.
17:29:50 <cohosh> ah right
17:29:53 <arma5> (afk dealing with a human who just appeared. please accumulate questions you need me to answer and i'll be back in a bit)
17:29:57 <phw> (also related to our obfs4 bridge setup guide, which currently says that you shouldn't be running an exit if you run an obfs4 bridge)
17:30:09 <cohosh> my gut feeling is that it makes me uncomfortable to run both
17:31:21 <cohosh> catalyst: gaba: i think if the bootstrap reporting touches the pt spec it fits in with the sponsor, but idk about more tor-specific things
17:31:45 <cohosh> (i'm also new to the sponsor world and not so sure how we usually scope these things)
17:31:46 <phw> in a world where we have plenty of bridges i would agree.
17:34:11 <cohosh> okay, i suppose the "please don't do this" can be easily ignored by an adversary anyway
17:34:38 <gaba> ok. can somebody estimate that ticket to see if it is a big one or not?
17:34:57 <phw> i think the threat here is well-meaning people running both a bridge and an exit, and then having their ssh key compromised or something similar.
17:35:05 <cohosh> ah good point
17:35:34 <catalyst> if there's a large enough number of middle nodes, an adversary running both a bridge and an exit should have a difficult time correlating network flows between the bridges and the exits, right?
17:36:28 <phw> catalyst: i don't follow -- how does the number of middle nodes change the odds of this happening?
17:37:47 <phw> ...there's a ticket somewhere about incorporating bridges in families
17:38:08 <phw> #21864
17:39:38 <catalyst> phw: i'm thinking more middle nodes, more sources of timing randomness that make it harder to correlate bridge traffice with exit traffic? i've never quite been sure of the utility of MyFamily
17:39:42 <cohosh> okay so implementing this would be best (letting people run both but making sure one person's traffic doesn't go through both)
17:41:50 <phw> catalyst: ah, got it.  i think it does make it harder but not as much as we want it to.
17:42:27 <phw> i think it would be a good start to enumerate the actual threats of well-meaning people running both a bridge and an exit
17:43:28 <catalyst> phw: e.g., does it make it easier for a global passive adversary if someone runs both bridges and exits?
17:44:19 <phw> catalyst: i think it can make it easier for a local adversary in certain situations; for example if the operators runs their bridges and exits in the same data center.
17:44:20 <cohosh> if we're mostly worried about an ssh key compromise and the tradeoff is more people get to evade censorship, i'd lean towards letting people run both in the short term before we fix the relay families to handle it
17:46:01 <cohosh> hmm it still makes me uncomfortable though
17:46:23 <arma5> catalyst: i think having tor know whether its bridge+PT is working, and if not why not, is worth doing, and race will benefit from it. we want it for automatic response to some PTs not working.
17:46:28 <cohosh> i guess s/letting/not discouraging
17:46:48 <catalyst> arma5: thanks
17:47:09 <arma5> my current view on MyFamily is that we should throw out the whole concept. it causes users to shift traffic from honest nodes to misbehaving nodes.
17:47:17 <arma5> (#15060)
17:47:57 <catalyst> arma5: i think that sounds like a good reason
17:48:53 <cohosh> arma5: do you have opinions about whether or not to discourage running both exits and bridge though?
17:49:31 <arma5> i think discouraging people from helping run tor network components is a bad move at this point
17:49:46 <arma5> we have been doing so little lately to encourage it, and the bridge count reflects this lack of attention
17:49:59 <arma5> so maybe in an ideal world we would want to not do it so much,
17:50:10 <arma5> but in the world we live in now, we need all the bridges and all the exits we can get
17:50:29 <arma5> that said, i wrote https://2019.www.torproject.org/docs/faq#RelayOrBridge and i think it's still right
17:50:52 <arma5> but i guess that is for bridgedb style bridges. for tor browser built-in bridges, it's a different calculus
17:51:06 <arma5> i would tend to say that anybody who can run exits should run more exits
17:51:34 * arma5 backs off so he doesn't clobber the actual agenda more :)
17:51:47 <cohosh> cool, that makes sense to me
17:52:45 <phw> thanks, that's helpful
17:52:57 <phw> i believe it was the last point on our agenda anyway -- anyone else who needs help/review?
17:53:20 <cohosh> i'd like some thoughts on the current plan for broker stats #21315
17:53:21 <gaba> and plese remember to update the roadmap board with what you are working on right now
17:53:24 <arma5> phw: is there some place i can look, to see what race tickets we're working on / plan to work on?
17:53:44 <gaba> there is a sponsor28 sponsor in trac now
17:53:54 <arma5> i also have a mostly drafted email to anti-censorship-team@ to get us started thinking about unclassifiable protocols
17:53:55 <gaba> we didn't start tagging them
17:54:17 <phw> https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~sponsor28 as gaba said.  i'll start creating tickets.
17:54:24 <gaba> but we talked about a few other tickets to add and they are in the roadmap in storm
17:54:37 <arma5> ok great. i will proceed with an algorithm of "telling phw or gaba when something seems important", and we can adapt from there :)
17:54:49 <gaba> we have a tag for tentative ticket into the roadmap
17:55:20 <gaba> phw: the sponsor query is https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&sponsor=%5ESponsor28&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&order=priority
17:55:54 <phw> i can't make my window large enough to have it fit in one line
17:56:21 <gaba> in the sponsor field there is a Sponsor28 and Sponsor28-can and Sponsor28-must
17:56:42 <gaba> those 3 values for that field can indicate (was we do with other sponsor) if a ticket should be included to work on or not
17:57:21 <gaba> For indicating that a ticket is in the anti-censorship roadmap we are using the keyword 'anti-censorship-roadmap'
17:57:48 <phw> let's please add special tags to https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#Tractags
17:58:10 <gaba> Yes. We have the fields keywords and sponsor in trac. Those are two different fields.
17:58:14 <catalyst> meta-question -- if there's both SponsorX-can and SponsorX-must, should SponsorX with no suffix ever be assigned? (it can still be useful for "starts with" searches)
17:58:47 <gaba> yes, ideally we should have X-can and X-must
17:59:28 <gaba> I will add at the bottom of https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam the active sponsors (the same as we have in https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam)
17:59:36 <phw> thanks gaba!
17:59:53 <phw> ok, let's wrap it up for today.  thanks everyone!
17:59:56 <phw> #endmeeting