16:59:54 #startmeeting anti-censorship weekly checkin 2019-05-30 16:59:54 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:57 hi everyone o/ 17:00:08 Hello! 17:00:14 hi! 17:00:49 fyi, here's our meeting pad: https://pad.riseup.net/p/tor-censorship-2019-keep 17:01:07 a brief announcement: as part of our sponsor 28 work, we will revise our PT spec 17:01:36 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 once we have a good idea of the shortcomings, we will revise the spec 17:02:25 we are at step 0 for this, but it's an exciting task, so i figured it's worth an announcement 17:03:38 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 i will then turn the pad into our monthly report for may 17:05:05 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 hi! 17:05:29 is gaba here? 17:05:38 hi gaba! 17:05:41 hi o/ 17:05:45 i/ 17:05:47 o/ 17:06:28 * phw wonders if he should continue his monologue 17:06:44 o/ 17:07:03 gaba: did you have something for ahf's discussion point? 17:07:12 phw:let's skip the discussion from ahf until he is here 17:07:37 no, we want ahf to be a liason for anything that may need to be worked on network-team side 17:07:54 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 the next two points are cohosh's. 17:08:06 * phw hands the mic 17:08:10 oh, catalyst is here :) 17:08:13 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 catalyst: do you have any point related to line 36 on the pad 17:08:37 arma5: ok, good to know 17:08:55 so the first point is about near and future changes to snowflake 17:09:28 gaba: i think right now mostly #30639 17:09:29 we want to add some kind of simple sequencing layer between the client and proxies 17:10:07 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 there's not currently a versioning mechanism (we could add it for the future though) 17:10:32 and the question is about how to handle this 17:11:03 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 But in any case the question still stands with regard to client upgrades. 17:11:34 dcf1: ah that simplifies it a bit 17:12:05 we could probably make things backwards compatable but it would be messy 17:12:22 and maybe we'd want to eventually discontinue support of really old versions anyway 17:12:47 i have some thoughts but not gathered and probably not best to dredge them up off the cuff in the meeting 17:12:59 that's fair, there's no immediate rush 17:13:00 do we have a ticket for this? 17:13:29 we could make a ticket or just put it in ticket #25429 or #29206 17:13:59 when they are closer to being in review 17:14:21 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 i'll probably ask for an early incrememntal review anyway 17:14:39 yup good point 17:15:00 if we ever change how any of the snowflake pieces talk to each other this will come up 17:15:07 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 cool 17:15:34 seems like backward compatibility is not so big a deal with so few users. yeah. 17:15:36 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 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 the next point is about the obfs4 probe tests we've been doing 17:18:04 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 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 What is the answer? 17:19:27 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 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 Cool. 17:20:13 do we understand any more about the active probing triggering 17:20:18 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 like, are we not causing active probing? 17:20:50 arma5: i have some .pcap files I can check, but i wasn't specifically looking for it 17:21:09 it might be worthwile to set up a new active probing test like the one-off ones phw was doing? 17:21:40 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 important 17:22:03 it's certainly something josh will want to hear about 17:22:14 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 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 keen 17:22:48 \o/ 17:23:06 that's it for me for discussion :) 17:24:28 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 okay will do 17:24:44 thanks! 17:25:29 ok, who needs code review or help with anything? 17:25:56 I just need you to sign off on the report. :-) 17:26:01 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 kat5: yes, i'll get to it right after the meeting! 17:26:15 catalyst was bringing #30639 . I think is mostly to see if this fit into the RACE work, no? 17:26:16 tyvm 17:26:45 gaba: which sponsor is RACE? 17:27:26 the new one on PT work 17:27:35 s28 following some of the work from s19 17:27:43 phw: i'll take a look at the wiki after this meeting 17:27:55 does s28 cover improving bootstrap reporting? 17:27:58 gaba: hmm, i'm not sure if i see the link to race...? 17:28:03 or is it more tightly scoped to PTs? 17:28:34 yes 17:29:19 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 ah right 17:29:53 (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 (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 my gut feeling is that it makes me uncomfortable to run both 17:31:21 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 (i'm also new to the sponsor world and not so sure how we usually scope these things) 17:31:46 in a world where we have plenty of bridges i would agree. 17:34:11 okay, i suppose the "please don't do this" can be easily ignored by an adversary anyway 17:34:38 ok. can somebody estimate that ticket to see if it is a big one or not? 17:34:57 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 ah good point 17:35:34 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 catalyst: i don't follow -- how does the number of middle nodes change the odds of this happening? 17:37:47 ...there's a ticket somewhere about incorporating bridges in families 17:38:08 #21864 17:39:38 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 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 catalyst: ah, got it. i think it does make it harder but not as much as we want it to. 17:42:27 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 phw: e.g., does it make it easier for a global passive adversary if someone runs both bridges and exits? 17:44:19 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 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 hmm it still makes me uncomfortable though 17:46:23 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 i guess s/letting/not discouraging 17:46:48 arma5: thanks 17:47:09 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 (#15060) 17:47:57 arma5: i think that sounds like a good reason 17:48:53 arma5: do you have opinions about whether or not to discourage running both exits and bridge though? 17:49:31 i think discouraging people from helping run tor network components is a bad move at this point 17:49:46 we have been doing so little lately to encourage it, and the bridge count reflects this lack of attention 17:49:59 so maybe in an ideal world we would want to not do it so much, 17:50:10 but in the world we live in now, we need all the bridges and all the exits we can get 17:50:29 that said, i wrote https://2019.www.torproject.org/docs/faq#RelayOrBridge and i think it's still right 17:50:52 but i guess that is for bridgedb style bridges. for tor browser built-in bridges, it's a different calculus 17:51:06 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 cool, that makes sense to me 17:52:45 thanks, that's helpful 17:52:57 i believe it was the last point on our agenda anyway -- anyone else who needs help/review? 17:53:20 i'd like some thoughts on the current plan for broker stats #21315 17:53:21 and plese remember to update the roadmap board with what you are working on right now 17:53:24 phw: is there some place i can look, to see what race tickets we're working on / plan to work on? 17:53:44 there is a sponsor28 sponsor in trac now 17:53:54 i also have a mostly drafted email to anti-censorship-team@ to get us started thinking about unclassifiable protocols 17:53:55 we didn't start tagging them 17:54:17 https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~sponsor28 as gaba said. i'll start creating tickets. 17:54:24 but we talked about a few other tickets to add and they are in the roadmap in storm 17:54:37 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 we have a tag for tentative ticket into the roadmap 17:55:20 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 i can't make my window large enough to have it fit in one line 17:56:21 in the sponsor field there is a Sponsor28 and Sponsor28-can and Sponsor28-must 17:56:42 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 For indicating that a ticket is in the anti-censorship roadmap we are using the keyword 'anti-censorship-roadmap' 17:57:48 let's please add special tags to https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#Tractags 17:58:10 Yes. We have the fields keywords and sponsor in trac. Those are two different fields. 17:58:14 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 yes, ideally we should have X-can and X-must 17:59:28 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 thanks gaba! 17:59:53 ok, let's wrap it up for today. thanks everyone! 17:59:56 #endmeeting