17:00:20 #startmeeting anti-censorship weekly checkin 2019-06-20 17:00:20 Meeting started Thu Jun 20 17:00:20 2019 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:23 hi everyone o/ 17:00:38 our meeting pad is available here: https://pad.riseup.net/p/tor-censorship-2019-keep 17:00:40 hi o/ 17:01:02 hello 17:01:13 no announcements today. gaba, do you wanna take the first discussion point? 17:01:19 yes 17:01:32 I remember we talked at some point about moving one of the projets to gitlab 17:01:35 snowflake 17:01:46 so I created an account in gitlab and exported tickets from trac 17:02:01 (mostly for learning what it would mean to do this misgration into gitlab from trac...( 17:02:04 ) 17:02:17 but do we want to do it? if we do then what do we need? 17:02:53 we already did this for gettor, right? how did that go? 17:03:07 yes, but gettor is only hiro working on it right now 17:03:14 the best way for the org to evaluate GL is to get some hands on experience, so the more "smaller" projects we can move the more knowledge we'll have before we consider moving over some of the "big" projects 17:03:15 it seems to be working well so far 17:03:15 cool, i think it's worth trying out and snowflake seems like a good self-contained project to try it out on 17:03:48 the big issue is to keep sync gitlab-trac from tickets filled in trac 17:03:51 it sounds like a good idea to me as long as it doesn't cause significant friction for snowflake development 17:03:57 but i can keep up with that task while we do the transition 17:04:25 phw: yes, i don't see any more work from development perspective but i may be missing something 17:05:02 i guess we'll keep pushing to the gitweb repo as well while we're trying it out 17:05:11 cohosh, ahf: you are the ones doing snowflake development the most. something else to consider? 17:05:12 i think we can setup sync hooks 17:05:13 is the eventual idea to make the gitweb repo a mirror? 17:05:24 we can have it as a mirror while we transition? 17:05:27 so we can have merge to gitlab, sync to gitweb 17:05:32 ah ok 17:05:41 i think hiro has set that up elsewhere, right hiro? 17:06:00 ok. I will have all this in a document to plan better to be sure we are not forgetting anything 17:06:01 gaba: i'd ask dcf1 and cohosh as the primary people here 17:06:08 ahf: ok 17:06:25 how many tickets do we have on trac for SW? right now the headlines are moved, right? 17:06:26 another thing to consider is that there's a long tail of people who know to look for tickets on trac 17:07:01 ahf: i moved all tickets (around 120) but only number and title. Then I went through the roadmap and replicated in the board in gitlab. 17:07:16 ahh, cool 17:07:19 For each ticket in the roadmap for snowflake we have description, sponsor info and link to the trac ticket. 17:07:43 what's the link to the snowflake gitlab repo now? 17:07:50 If we start working on tickets in gitlab for snowflake then it would makes sense to link to gitlab from trac 17:08:22 cohosh: https://dip.torproject.org/anti-censorship/pluggable-transports/snowflake/boards) 17:08:33 cohosh: https://dip.torproject.org/anti-censorship/pluggable-transports/snowflake 17:08:40 gaba: thanks! 17:09:14 can anyone create issues on dip.tp.o? 17:09:21 I also changed permissions and gave all people in the team ownership... 17:09:46 phw: i just asked that question in #tor-project, i'm not sure if we have solved the guest login part yet 17:10:07 gotcha, thanks ahf 17:10:09 pwh:let me check 17:10:14 ahf: i don't want us to end up with the cypherpunks problems again 17:10:22 oh right 17:10:37 yes, only people with access :/ . There is no option in gitlab to change it 17:10:42 catalyst: do you mean the account being abused? 17:10:46 catalyst: i'm not sure i know which problem it is? having anonymous users or having non-ldap guest users? 17:10:49 ok. I think it would makes sense to do the change when we have this resolved. 17:10:58 i think we are missing to solve the issue where people can sign up outside of LDAP users 17:11:22 We need people to be able to create issues without login. 17:11:42 i do think maybe we are passed the time where an anonymous user is a good idea, but maybe that is just me being boring. don't know how the rest of the org thinks 17:12:07 shared anonymous user that is - everyone should be able to sign up 17:13:06 we should make it easier for contributors to open tickets but that's not a snowflake-related issue. 17:13:15 yes 17:13:20 yes, agreed 17:13:22 is there anything else we should discuss as part of this gaba? 17:13:35 Here are cypherpunks-filed Snowflake tickets: https://trac.torproject.org/projects/tor/query?component=Circumvention%2FSnowflake&reporter=cypherpunks&or&keywords=~snowflake&reporter=cypherpunks&order=priority 17:13:43 not so far. Everybody ok with us waiting for this to get resolve first? 17:14:01 sounds good to me. 17:14:15 ok 17:14:22 ("this" is guests being able to file tickets, right?) 17:14:29 dcf1: all thos tickets seem quite valid 17:14:34 phw: yes 17:15:12 ok, the next discussion item is mine 17:15:20 we should make sure that the barrier for opening tickets is at least as low as trac 17:15:24 hopefully lower 17:15:37 yes, agreed 17:15:52 our obfs4 setup guide should be in good shape now: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy 17:16:03 there remain a number of UX-related tickets for bridge operators, though 17:16:20 neat 17:16:42 #29128 is particularly annoying 17:17:12 i wonder how hard it would be to have this fixed. catalyst or ahf, do you have any idea? 17:17:33 i'm reading the ticket 17:17:41 looking... 17:17:50 oh 17:17:51 very easy now! 17:17:56 :o 17:17:59 the obfs4 could write it to the Tor's log output now i think? 17:18:32 that's certainly one solution. however, there was some concern that bridge ops may accidentally paste their bridge lines somewhere public 17:18:33 so when the server starts up it tells the tor process to log at NOTICE log level what its config line is 17:18:43 hm 17:18:46 yeah 17:19:29 i'm not sure how to make it both easy and hard for the admins to not mess up 17:19:44 obfs4 doesn't know its bridge fingerprint though, right? so tor would have to augment obfs4's message somehow? 17:19:53 we remove certain things from the tor logs to avoid people pasting them online 17:20:06 Right, obfs4proxy doesn't itself know all the necessary information. 17:20:09 hm, true 17:20:33 i like the idea of tor writing the bridge line to pt_state/obfs4_bridgeline.txt 17:21:04 pt_state/ i think is reserved for the PT's themselves to use, no? so tor shouldn't mess around in there? 17:21:31 we could have the PT tell tor what arguments it wants and tor could construct the torrc friendly complete line and output with some warnings around it 17:21:32 could tor tell the PT to write the line out somewhere? 17:21:34 first time the bridge start 17:21:35 tor knows all the information because obfs4proxy reports it using SMETHOD ARGS: messages (I believe). 17:22:04 "have the PT tell tor what arguments it wants" that's SMETHOD ARGS: (pt-spec 3.3.3) 17:22:44 That's how those parameters eventually get communicated to BridgeDB, so tor already has that information. 17:22:49 i think the easiest fix would be to have tor do it because it already knows everything -- it has to write it into its extrainfo desc, after all. 17:22:54 yeah 17:23:30 we can have tor write it, but i think it would be on level above pt_state/ (in tor's own data dir) 17:23:39 i'm not opposed to simply logging the bridge line. a warning may be just fine. 17:24:24 should we create a core tor/tor ticket for this? 17:24:37 ahf: we could have a file, say, bridge-lines, that lists all transports that the bridge runs. 17:24:46 hm, wait, we can just use this one. this one is already core tor/tor 17:24:49 phw: yes 17:24:55 i think that would be a good idea 17:25:00 and very easy to add 17:25:05 yes, let's continue in #30331 17:25:13 thanks, all 17:25:18 sweet 17:25:30 i went off on a tangent here 17:25:40 what i meant to discuss was the obfs4 setup guide :) 17:25:49 oh :-) 17:26:04 we need new bridges and, with stephw's help, will do an outreach campaign to attract new operators 17:26:20 before that, we should do a "test run" to find issues with the guide 17:26:21 cool! 17:26:32 i think a simple email to tor-relays@ would get this done 17:27:10 any other ideas? if not, i'll send the email later today 17:27:31 i think email, blog posts, try to get people in the org to tell people they meet on their way to run bridges instead of relays could be good 17:27:34 or both 17:27:53 i've started trying to push people to run bridges instead of relays, but that have probably very limited impact :-S 17:28:52 sounds good, thanks ahf 17:29:06 just to confirm: emailing @relays is a test run for a broader campaign to get more bridges right? 17:29:15 cohosh: yes 17:29:21 cool 17:29:32 we don't want to publish a blog post etc., only to discover that here are embarrassing issues in the guide. 17:29:38 (i don't think there are, but hey, who knows) 17:29:43 yep that sounds like a good idea 17:30:06 thanks, i'll move forward with this later today, then 17:30:11 the next discussion point is ahf's 17:30:13 * phw hands the mic 17:30:17 cool 17:30:32 so cohosh and i talked last week about the snowflake patches in here: https://github.com/ahf/snowflake/tree/features/websocket_r5 17:30:53 there is both code to add a websocket+json based protocol in here and a single patch to add authentication (using P256) 17:31:10 all the patches together are a bit more than a doubling of snowflake's source code size, which is not super good 17:31:26 so we decided to ignore authentication for now, and rip that out and focus on the websocket part 17:31:46 and make sure that the broker can be started up with a command line flag that disables the websocket listener in case there is a bug in the code 17:32:02 cohosh: anything i forgot here? :-S 17:32:20 and then to make sure that both websocket and non-websocket (polling) nodes can talk to each other, of course, that part is missing right now 17:32:21 this is a possible motivation example: #30704 17:32:52 dcf1: is there some concers you may have with the above ^^ or do you think that sounds like reasonable steps 17:33:16 i think there's a desire for another layer in the communication between snowflake pieces 17:33:24 To be honest I never understood the purpose of the websocket branch, so I don't have any opinion now. 17:33:53 okay 17:34:00 part of the story around this too is that this is osmething that came up during the brussels team meeting 17:34:00 cohosh: in what way? 17:34:11 I'm not necessarily opposed. 17:34:20 and then there was some confusion and lack of communication about who was working on what 17:34:52 and now on our side of things we are becoming more familiar with snowflake as a project 17:35:24 we can entirely decide to ditch websockets support, i'd not be hurt in any way by doing that, i think that is an option we have 17:35:43 i think the benefits are way more there from a protocol extension point of view in the future, especially with if we wanted authentication 17:35:52 ahf: re the layer, see dcf1's comments on the ticket above 17:36:05 i think at brussels we were thinking using the websocket protocol was one way to do that 17:36:25 and the other motivating factor was to see if it was a better method than the current 10s polling that proxies do 17:36:30 reading 17:36:44 but I don't think we have enough information (yet) to know if that's even something that can/should be improved 17:37:01 10s is probably far too often 17:37:17 cohosh: agreed 17:37:50 The nice thing is that the broker--proxy link is pretty much independent from all the rest; it's possible to change it without requiring client and server to upgrade. 17:38:10 And there are many reasonable ways to implement it, doesn't have to be perfect. 17:38:20 dcf1: yup makes sense 17:38:21 I also think 10s is too much, flash proxy used 600s. 17:38:38 the current method also have the benefit of being stateless where the websocket connections are stateful 17:39:00 we could extend the current system with authentication if wanted that too, in a "simple" way later on too 17:39:31 arlolra: dcf1: makes sense, though we probably need more proxies first, since clients can't connect unless a proxy is currently polling 17:39:38 The current method is a little bit stateful, the broker has to connect two separate proxy requests, the first that gets the client offer, and the second that uploads the proxy answer. 17:40:27 right, there is the period where we need to store state between requests 17:42:11 (sorry that I just added two more management things to the pad...) 17:42:40 :-D 17:43:03 ok, so, should we decide here and now that the discussion continues on #30704 which seems to be more like a JSON protocol with ordinary HTTP without websockets 17:43:19 and probably a lot less code change than what i have in the branch? 17:43:58 (i don't know enough about snowflake to have an informed opinion, so i defer to others) 17:44:07 It's a valid and worthwhile exploration at any rate, thanks ahf. 17:44:14 :-) np! 17:44:23 yeah thanks, and the long term identifier work looks really nice 17:44:50 we should make sure we update the ticket for that pointing to the work you've done so far 17:44:51 cool, let's do that then. i don't think i have more on this point then :-) 17:44:56 cohosh: agreed 17:45:02 i'll write a comment there after the meeting 17:45:07 gaba: you're next 17:45:21 ok. first one is about trac 17:45:48 it would be good for people to only own what they are working on. Not sure if you are all using that field for something else 17:46:14 gaba: for both what we're working on now *and* in the future, right? 17:46:23 phw: what do you mean? 17:46:38 phw: for all the tickets that are on your plate right now. 17:46:43 i own tickets that i intend to work on in a few weeks from now. 17:46:50 phw: yes, that is ok 17:46:54 gaba: i think the "assigned" vs "accepted" distinction might be useful to someone in phw's situation 17:47:16 catalyst: yes, that sounds good. you can accept the ticket and own it if it is on your list 17:47:25 ok, gotcha 17:47:44 * cohosh just realized there's an "accepted" status 17:47:46 the second issue i was bringing is to see how we are doing with #23888 17:47:55 arlolra ^ 17:47:58 i've tried to start doing that -- if i think i'll get to a ticket soon but i'm not actively working on it, i'll put it back in "assigned" 17:48:39 i'll try doing that too, thanks catalyst 17:48:50 makes sense 17:48:52 sorry for being slow 17:49:01 this meeting conflicts with my deploy window 17:49:03 anyways 17:49:10 I opened #30931 17:49:41 I think we can close #23888 and start filing individual tasks for bugs and features 17:49:49 with the webextension keyword 17:50:02 arlolra: do you have an estimate on when this one could be completed? any help needed? 17:50:27 arlolra: what kind of accounts? is this something related to the firefox/chrome "store"? 17:50:28 gaba: the webextension works at the moment as a proxy 17:50:29 * phw is ignorant 17:50:40 phw: yes, exactly 17:50:50 accounts for addons.mozilla.org, yes. 17:50:53 * gaba is going to close #23888 and have it as a child of #30931 to express teh relationship there 17:51:18 I have an accounts.firefox.com accounts, I'm not sure if that's the same. 17:52:51 what's the update process for web extensions? 17:52:54 arlolra: are you ok if dcf1 takes #30931 . dcf1: ok? 17:53:05 like if someone installs our extension and then we have a fix to push out 17:53:17 cohosh: you prepare a new zip bundle with a new version number and upload it. 17:53:20 gaba: if they want it 17:53:29 okay cool, and firefox will handle the udate automatically? 17:53:34 or chrome or whatever 17:53:50 gaba: I think #30931 is more about deciding on how to handle shared access, whether the addons store supports multiple accounts or if we need to share an account, things like that. 17:54:07 dcf1: that was my intention, yes 17:54:14 feel free to update the description 17:54:51 i'll put this on my todo list, arlolra 17:55:55 arlolra: do you need help with anything else? 17:56:06 we should probably try to publish early in case it takes a while to approve a first version 17:56:32 phw: nope 17:56:37 publishing an addon involves a mozilla person reading your code, right? 17:57:00 we're almost out of time 17:57:13 phw, in theory yes, they also run some automated tests for obvious malware. 17:57:22 gotcha 17:57:27 so, to be clear. who is taking #30931? :) 17:57:40 gaba: i will. unless anybody else wants to. 17:57:43 thanks! 17:58:01 who else needs help or code review? 17:58:08 oh, code reviews 17:58:12 there is one not assinged in the list 17:58:26 #29347 17:58:35 fwiw, i'm increasingly thinking about PT spec improvements and features for the obfs4 successor and i'd like to hear from anyone who has opinions on this. 17:58:47 gaba: i'll take that one out of needs_review 17:58:54 dcf1: thanks 17:59:29 Looks like #21315 and #25483 need help. 17:59:47 i'm waiting on the metrics team for #21315 17:59:52 but i could do a trial deployment 18:00:05 and keep the stats local just to see what we get 18:00:09 Right, I saw the ticket update. 18:00:11 irl is on leave. Let's wait until he is back. 18:00:38 I meant, if you want irl's feedback then it makes sense to wait until he is back. 18:00:39 for #25483, i'm looking into pion/webrtc right now which seems promising 18:00:45 gaba: okay ack 18:01:15 cohosh: agreed, pion/webrtc seems more likely to be fruitful. 18:01:26 i'm curious about the windows libraries that seem to be missing from the mingw/clang toolchain 18:01:33 but i'm not stuck on it 18:01:51 which libraries is it? 18:02:28 oldnames, cmtd, cpmtd 18:02:31 cohosh: i think it's fine to start collecting metrics locally. aiui, gaba just pointed out that irl isn't around right now; not that we have to wait for him. 18:02:45 cool, sounds good 18:02:58 hm, ok :o 18:03:24 i don't know much about windows development, but these are the windows SDK libraries libwebrtc needs 18:03:33 and I can get them in .lib form but not .a form 18:04:05 cohosh: is your "needs help with" section answered? 18:04:15 phw: yeah i think i'm good for now 18:04:20 great 18:04:24 let's wrap this up then 18:04:27 #endmeeting