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