17:00:14 <phw> #startmeeting anti-censorship weekly checkin 2019-08-22
17:00:14 <MeetBot> Meeting started Thu Aug 22 17:00:14 2019 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:14 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:18 <phw> hi everyone
17:00:25 <dcf1> hi
17:00:32 <phw> our meeting pad is available here: https://pad.riseup.net/p/tor-censorship-2019-keep
17:00:40 <gaba> hi
17:01:00 <catalyst> hi
17:02:24 <phw> our first discussion item is a mailing list post on tor-relays@: https://lists.torproject.org/pipermail/tor-relays/2019-August/017647.html a relay was dealing with a lot of connections from iranian addresses iiuc
17:02:53 <phw> i have no idea what this might be all about. maybe related to #30636?
17:03:45 <phw> but maybe anyone else has a guess?
17:04:32 <dcf1> IR user numbers are much elevated since the baseline a few months ago, but pretty steady the last 2 months.
17:04:35 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2019-05-01&country=ir
17:06:20 <dcf1> I hadn't heard about this, but I don't see any clear connection to censorship, except that it was Iranian(?) IPs connecting to an exit(?) relay.
17:06:40 <phw> yes, that was my thought too
17:07:13 <phw> anyway, let's move on. i was just curious if anyone could make more of this post.
17:07:43 <phw> we have the gettor roadmap: https://dip.torproject.org/torproject/anti-censorship/gettor/-/boards
17:07:47 * phw wonders if hiro is here
17:08:31 <gaba> hiro: you had some plans for next steps for gettor
17:08:50 <phw> i think the tor browser copies in github/gitlab are outdated
17:09:07 <gaba> phw: what do you mean?
17:09:30 <phw> the links that gettor sends you over email are outdated. it should give you the latest tor browser copies but it doesn't.
17:09:31 <dcf1> I heard that as well. Someone at FOCI said they had set up their own Tor Browser distribution on GitHub to work around tpo's being outdated.
17:09:43 <gaba> ah, yes
17:10:00 <phw> this shouldn't be too hard to automate, i would think. if only we had enough time to work on it :/
17:11:05 * gaba is looking for a ticket about tor browser outdated in gettor links
17:11:12 <dcf1> https://github.com/TheTorProject/gettorbrowser links to 8.0.2
17:12:11 <phw> also, we really really need some basic documentation. i started https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam/GetTorSurvivalGuide
17:12:16 <dcf1> which is from last October https://blog.torproject.org/new-release-tor-browser-802
17:13:17 <gaba> can any of you create a ticket for the links being outdated?
17:13:25 <phw> will do, gaba
17:13:30 <gaba> thanks!
17:13:41 <phw> anyway, let's talk more if hiro shows up and continue in the meanwhile
17:13:46 <gaba> It seems that updating that and automatizing should be a prioirity
17:13:49 <gaba> yes
17:13:58 <hiro> I was here sorry updating the pad
17:14:10 <phw> hi hiro!
17:14:21 <hiro> yes the links got outdated when the recommended browser version changed
17:14:25 <hiro> I have to fix that
17:14:31 <hiro> I have it for this week
17:14:44 <hiro> it is automated via gitlab pipeline pushing to github and gitlab
17:15:13 <phw> hiro: oh, the updating process already is automated?
17:15:16 <hiro> yes
17:15:20 <phw> neat
17:15:33 <hiro> everyday there is a CI checking the browser version
17:15:36 <hiro> and updating the files
17:15:46 <hiro> problem is it's broken atm
17:16:20 <phw> how can we help fixing it?
17:16:43 <hiro> I have it for today
17:16:45 <hiro> to fix it
17:17:03 <hiro> I will nevertheless give you access to the repository where the pipeline lives
17:17:13 <hiro> I think atm only me and dgoulet have access
17:18:07 <hiro> becaue dgoulet set up that gitlab account
17:18:44 <hiro> anyways today it will be fixed
17:19:14 <phw> cool, thanks hiro
17:19:21 <gaba> anything else that is urgent related to gettor?
17:19:22 <phw> anything else that's critical in gettor?
17:19:26 <gaba> hehe
17:19:45 <hiro> I think this and documenting everything
17:19:50 <hiro> also having a better deploy method
17:20:03 <hiro> this is the ci: https://gitlab.com/thetorproject/gettorbrowser/blob/master/.gitlab-ci.yml
17:20:10 <phw> documentation would be very helpful because it allows others to take over and contribute without relying so much on hiro
17:20:35 <gaba> hiro: do we have tickets in trac for deployment? if we don't please create one and we link it to the roadmap for next week
17:20:40 <clash> I'm just reading but is there a way to utilize webhooks here?
17:20:54 <hiro> webhooks from gitlab?
17:20:59 <clash> whenever there's a new TB release Gettor gets the new builds
17:21:20 <hiro> I am using ci in gitlab
17:21:29 <clash> oh
17:21:48 <clash> are there webhooks wherever the original builds are hosted?
17:21:59 <hiro> on dist.tpo
17:22:10 <hiro> it's just files listed on apache
17:22:24 <phw> how about we continue with the roadmap once we have addressed the critical issues in gettor?
17:22:28 <hiro> for reference clash: https://gitlab.com/thetorproject/gettorbrowser/blob/master/.gitlab-ci.yml
17:22:30 <phw> what do you think gaba?
17:22:42 <gaba> phw: yes, sounds good
17:23:03 <gaba> I just updated with the work hiro is planning for next week
17:24:15 <phw> let's move on to release engineering. here's how it works for bridgedb:
17:24:55 <phw> we're using semantic versioning for bridgedb's version number and this git development model: https://nvie.com/posts/a-successful-git-branching-model/
17:25:06 <phw> every now and then, when i have time, we're releasing a new bridgedb version
17:25:31 <phw> that's about it. we get away with this rather informal process because we are running the only bridgedb deployment ;)
17:26:12 <phw> gaba: you were thinking about topics like planned releases, right?
17:26:35 <phw> i'm trying to understand what we should be doing that we aren't doing already.
17:26:39 <gaba> yes. I was wondering if there is any release that should be better if planned.
17:26:56 <gaba> would*
17:27:33 <gaba> gettor is in a similar situation than bridgedb
17:27:34 <phw> do you mean by that "we have a new release every month" or "we anticipate feature X to release on Y"?
17:28:07 <gaba> That we put features/bug-fixing/changes together to release all at the same time (depending on minor or major changes)
17:28:33 <gaba> how is working with snowflake?
17:28:59 <gaba> phw: if we are ok this way and we do not need to change to a schedule then is fine with me.
17:30:09 <dcf1> With snowflake we have been making releases only as needed, for example pushing new proxy code to the website and making new webextension uploads whenever we need new proxy behavior
17:30:10 <phw> basically, that's what we are doing with bridgedb because of https://nvie.com/posts/a-successful-git-branching-model/. i'm a fan of this method. basically, the master branch only has releases while the development branch is for, well, development. new features and bug fixes branch off of the development branch and are eventually merged back into the master branch.
17:30:25 <dcf1> or upgrading the client in Tor Browser whenever we need new client behavior
17:31:14 <gaba> yes. I like having the develop branch as the source and not master.
17:31:35 <gaba> ok. thanks
17:32:16 <phw> i'm all for getting more organised but i'm not sure if i see a problem here that needs solving.
17:32:31 <gaba> yes, it seems we are fine and we do not need anything else on planning here.
17:32:49 <phw> do you see a need to improve things on snowflake's side dcf1?
17:33:30 <dcf1> The only thing is we're disorganized when it comes to updating all the channels, e.g. with publishing a new webextension and also updating the hosted proxy at snowflake.torproject.org.
17:33:56 <dcf1> But we don't really have critical dependencies that *require* close coordination.
17:35:15 <dcf1> Example is https://trac.torproject.org/projects/tor/ticket/31250#comment:12, which is still open because I don't know if Cupcake has updated yet.
17:36:26 <phw> a somewhat related thought: bridgedb could really use a staging server. many bugs only manifest once they're in production and messing with our production server is a very sloppy way of debugging.
17:37:12 <phw> but i guess that's more quality assurance and less release engineering
17:37:40 <gaba> yes, still important. Let's check with anarcat on how to get one
17:37:52 <anarcat> hum?
17:38:21 <hiro> hey phw gaba isn't bridge db on a special server?
17:38:31 <phw> hiro: it's on polyanthum
17:38:36 <hiro> w special I mean a bare metal that has specifc requirements?
17:38:42 <phw> oh, that i don't know.
17:38:47 <gaba> dcf1: not sure what we would be next step with #31250. Is this something about coordinating with somebody else not here?
17:39:30 <hiro> also bridgedb gets bridges from the bridges authority do you plan to have a staging w real bridges or just test addresses?
17:39:31 <dcf1> gaba: nothing we need to talk about now. It's mostly solved. Just need to confirm with saint whether it's happened in Cupcake yet or not.
17:39:54 <gaba> ok
17:39:58 <hiro> I can help you setup this as when I setup the azure meek I did some testing with a bridgedb instance
17:40:35 <phw> hiro: i may be naive, but a second bridgedb instance on the same machine may be helpful. i don't want it to be used by people, but i want it to operate on the same bridges as the live instance.
17:41:10 <anarcat> worst that can happen, on the same machine, is it takes the machine down because of resource usage
17:41:14 <anarcat> or that operators confuse the two
17:41:21 <hiro> yes!
17:42:04 <phw> if it's on the same machine, i would want it at, say, bridges.tp.o/staging/. operators wouldn't be exposed to it unless they are actively looking for it.
17:42:27 <phw> anyway, let's file a ticket and continue there, ok?
17:42:36 <hiro> ok
17:42:41 <anarcat> i won't see it until sept 3rd, btw
17:42:41 <phw> thanks hiro and anarcat
17:42:47 <anarcat> i'm on vacation for a bit
17:42:52 <hiro> enjoy vacas!
17:42:53 <anarcat> but weasel's around
17:42:54 <phw> it's not urgent
17:43:25 <phw> ok, next point on our discussion list is snowflake localisation!
17:43:41 <phw> you should all know that snowflake means schneeflocke in german
17:43:42 <dcf1> *localization
17:43:47 <phw> :)
17:44:25 <antonela> copo de nieve
17:44:32 <gaba> it is not in the roadmap but emmapeel worked on it and now it is ready :)
17:45:01 * phw has approximately 0 experience with locali[zs]ation
17:45:08 <antonela> thanks emmapeel!
17:45:32 <gaba> We do not have to do it now but it would be good to include it in the roadmap for s28 work with snowflake
17:46:15 <phw> sounds good to me. i hope somebody can figure out how to make use of translations :)
17:46:54 <phw> ok, last point is bridgedb's anti-bot mechanism. i wanted to catch you up on what we've done so far
17:47:19 <phw> we recently deployed #31252 in an effort to make it harder for bots to fetch bridges
17:48:32 <phw> i recently set up a decoy bridge that is handed out to requests that are coming from bots. the only purpose of this decoy bridge is to try and find out what our adversaries are doing with it
17:48:55 <phw> remember that bridgedb sees tons of automated requests that are surprisingly good at solving our captcha
17:49:17 <phw> i had a brief look at the logs of my default bridge and almost all connections are coming from china
17:49:46 <dcf1> "default" as in default Tor Browser bridge? not the decoy you mentioned?
17:49:47 <phw> our vps in china cannot connect to my decoy bridge either.
17:49:57 <phw> sorry, s/default/decoy/
17:50:16 <dcf1> The decoy is only given to suspected bots?
17:50:16 <phw> (the decoy bridge is private and doesn't report itself to the bridge authority)
17:51:19 <phw> that's it. i thought it's an interesting finding worth sharing.
17:51:19 <dcf1> I wonder why it would be made inaccessible and also connected to from addresses in China.
17:51:48 <phw> dcf1: my guess is that the bridgedb crawler is run by gfw engineers.
17:51:49 <hiro> maybe the bots are a way to discover bridges
17:52:31 <phw> i suspect that the decoy bridge ended up on the same "probing list" as all the other bridges that the gfw discovered by doing dpi
17:52:47 <dcf1> that would make sense
17:54:03 <phw> now that i think about it: i remember seeing connections to my bridge's obfs4 port. i wonder if they have a probing module for obfs4 but don't have a "detection module" for it
17:54:34 <phw> i'm happy to share the pcaps if anyone wants to have a closer look
17:55:43 <phw> ok, we're almost done for today. shall we move on to the "needs help with" part?
17:56:11 <dcf1> #31460 is a problem, yes.
17:56:15 <phw> i see that dcf1 already commented on #31460. that was a bug report from serna
17:57:10 <phw> i'll take the liberty of making cohosh the reviewer for #17626
17:58:18 <phw> arlo needs a review for #30310
17:58:38 <dcf1> It's one of the tickets I need to catch up on.
17:58:38 <phw> and dcf1 for #31454
17:59:42 <dcf1> I will do it if no one else does within a week.
17:59:47 <phw> i'll do #31454 with cohosh's help. i just updated to go 1.12.9 to re-deploy bridges.tp.o/scan/
18:00:02 <gaba> #30310 was for august but it has #31384 as a child. That last one may need to be for september.
18:00:58 <phw> i think we're done for today. anything left?
18:01:29 <phw> #endmeeting