17:00:07 <phw> #startmeeting anti-censorship weekly checkin 2019-10-03
17:00:07 <MeetBot> Meeting started Thu Oct  3 17:00:07 2019 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:07 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:15 <phw> hi everybody
17:00:25 <phw> here's our meeting pad: https://pad.riseup.net/p/tor-censorship-2019-keep
17:01:05 <phw> we have two announcements on bridge blocking
17:01:42 <phw> we just shipped a new default bridge in our most recent tor browser alpha and it already seems unreachable. unfortunately, i cannot tell when it started being unreachable -- that's a missed opportunity
17:02:07 <phw> we will however add more default bridges soon and should start measuring them the moment we know their ip address
17:02:45 <phw> thanks to cohosh, we also have new results on a random sample of bridgedb bridges
17:03:55 <phw> i'm mostly curious if the gfw is also crawling our moat interface. it's not easy to tell by the few http headers that we're seeing
17:04:02 <phw> i have yet to spend more time looking into it though
17:04:12 * phw proceeds to talk to himself
17:04:23 <cohosh> heh
17:04:44 <cohosh> so you mean change the logging on the bridgedb side to see if moat is getting crawled?
17:04:46 <gaba> hi!
17:04:59 <phw> as we discussed on irc earlier, it would be useful to do a properly designed experiment -- hence the section on research problems in our meeting pad
17:05:06 <cohosh> yeah
17:05:29 <phw> cohosh: no, i mean we see very little from the clients that use moat. it's a matter of what's visible, and not what's logged
17:05:52 <cohosh> ah because of the domain fronting
17:06:25 <phw> i think there are a handful of cases where we do get the client's ip address (over x-forwarded-for?) but i don't know why it's only a few
17:06:31 <phw> let me take a look at the recent bridgedb metrics
17:07:28 <phw> bridgedb-metric-count moat.obfs4.us.fail.none 90
17:07:28 <phw> bridgedb-metric-count moat.obfs4.cn.success.none 20
17:07:28 <phw> bridgedb-metric-count moat.obfs4.??.fail.none 2940
17:07:28 <phw> bridgedb-metric-count moat.obfs4.cn.fail.none 30
17:07:28 <phw> bridgedb-metric-count moat.obfs4.??.success.none 3420
17:07:30 <phw> bridgedb-metric-count moat.obfs4.us.success.none 90
17:07:31 <dcf1> If scapers are hitting the BridgeDb server directly (not going through the domain front), then you wouldn't get X-Forwarded-For probably.
17:07:50 <phw> dcf1: oh, i had not thought of that
17:08:13 <dcf1> Also the last time I looked, BridgeDB was processing X-Forwarded-For in the wrong order, meaning the address it looks at is not the original client address. I'm not sure if that's still the case.
17:09:05 <phw> i'll try to take a look soon
17:11:37 <dcf1> Comment on the X-Forwarded-For issue: https://trac.torproject.org/projects/tor/ticket/24432#comment:35
17:12:06 <phw> very useful, thanks dcf1
17:12:13 <dcf1> There's logic to ignore 127.0.0.1 in X-F-F, but AFAIK it's a workaround for the incorrect processing.
17:13:44 <phw> ok, in our discussion section we have a number of research ideas
17:14:21 <phw> i would like to turn these into short 1-2 paragraph summaries of projects that students and researchers can help us with
17:15:20 <cohosh> nice, these all look like good project
17:15:23 <cohosh> s
17:15:58 <phw> oh, and an additional announcement: thanks to hiro, we are now also hosting tor browser on archive.org as well as in a google drive folder.
17:16:07 <cohosh> \o/
17:16:13 <gaba> :D
17:16:14 <hiro> hey all
17:16:23 <hiro> about that gitlab.com/github accounts
17:16:36 <phw> this meeting feels like reading from a teleprompter :)
17:16:46 <antonela> lol
17:16:51 <hiro> I have checked reg who's budget should be to cover that (if we want it)
17:17:09 <cohosh> you are doing good phw
17:17:15 <hiro> and the question I have is why should it go to sysadmin if it will be used just for anti-censorship stuff (gettor)
17:17:52 <phw> gaba: is that something you can answer?
17:18:14 <hiro> also it's not expensive... 5$ per month for github (haven't checked gitlab.com)
17:18:23 <gaba> im not understanding hiro
17:18:39 <hiro> it's about who should pay for these accounts if we want them
17:18:49 <gaba> which account?
17:19:00 <hiro> gitlab.com and github.com to serve torbrowser files via gettor
17:19:05 <gaba> sysadmin are the only ones that have a budget :)
17:19:20 <gaba> how much are they?
17:19:27 <hiro> 5$ for github
17:19:32 <hiro> and I haven't checked gitlab
17:19:35 <gaba> per month
17:19:38 <hiro> yes
17:19:43 <hiro> so 60 per year
17:20:01 <gaba> ok. I will check with Isa on this and see if we can move it out of sysadmin budget
17:20:13 <hiro> ok
17:20:25 <hiro> sounds good to me
17:20:51 <phw> hiro: should we briefly talk about the mirror issue?
17:20:58 <hiro> yes that too
17:21:07 <hiro> what should we do about that?
17:21:18 <phw> so, we are talking about website mirrors of torproject.org, right?
17:21:21 <hiro> yes
17:21:41 <phw> and the goal is that people who cannot access our main website are still able to browse a mirror and download tor browser
17:21:59 <hiro> I think not all mirrors are download mirrors too
17:22:16 <gaba> how hard is for people to setup mirrors?
17:22:22 <hiro> many do
17:22:51 <hiro> it's not very hard in fact... and they send a message to tor-mirrors saying "hey I have  setup a mirror"
17:23:12 <hiro> and we ignore them at this moment because we were on a policy for which we were accepting mirrors only from trusted sources
17:23:13 <phw> as i understand it, a big issue is the authenticity of tor browser binaries that are hosted on mirrors, right hiro?
17:23:26 <hiro> the binaries and the information on the pages
17:23:31 <phw> in theory people could check the signature of a binary they got from a mirror but in practice... who does?
17:23:38 <hiro> how do we not know the pages aren't tracking the users?
17:23:51 <antonela> can we somehow discover new mirrors?
17:23:56 <gaba> so we should have a process to verify a mirror and say that is something people can trust
17:24:00 <hiro> we have certain standards also for things like our logs (what do we keep and what we do not store)
17:24:27 <hiro> gaba: the process should not be a 1-time thing, but it should be something we can countinously check
17:24:36 <gaba> right
17:24:53 <phw> gaba: that's tricky to get right. not only do we need to monitor mirrors continuously (they could be authentic at time t but malicious at t+1), we should also do the verification in a way that it's not easy for mirrors to be authentic towards us but malicious towards others
17:25:57 <hiro> or towards a subset of users, from a certain country for example
17:26:06 <phw> hiro: do or did we announce mirrors somewhere?
17:26:22 <phw> or in other words: how would one find out about mirrors?
17:26:23 <dcf1> (people will just search "download tor" on google anyway, and get it from cnet.com or filehippo.com)
17:26:57 <dcf1> (no matter how much you verify the mirrors, I mean)
17:26:58 <hiro> the old website used to have a list of mirrors
17:26:59 <antonela> yeah
17:27:04 <phw> dcf1: right, if i wanted to distribute malicious tor browser binaries, i would just try to get my site high up on search engines
17:27:08 <ggus> https://dip.torproject.org/torproject/web/tpo/issues/31
17:27:33 * antonela puts her face there
17:28:11 <hiro> https://2019.www.torproject.org/getinvolved/mirrors.html.en <- this is actualy the list
17:29:05 <antonela> who do maintain that list?
17:29:11 <cohosh> despite the fact that people can download malicious versions from anywhere, there's still value in maintaining a list of known trusted mirrors
17:29:14 <antonela> or is magically updated?
17:29:19 <hiro> at this moment no one
17:29:20 <antonela> cohosh +1
17:29:36 <hiro> there is a script in the old website repository that creates a page out of a csv file
17:29:41 <cohosh> idk how the solve the other problem though other than awareness
17:30:19 <antonela> maybe we can have a kind of file that new mirrors should have in their servers so we: 1. check security stuff 2. list them in that list
17:30:33 <antonela> not sure how hard it could be tho
17:30:39 <antonela> but is s30 stuff :)
17:30:44 <hiro> why would they need a file
17:30:47 <hiro> ?
17:30:58 <antonela> they dont need the file, we need the file to know they exists
17:31:01 <antonela> *exist
17:31:07 <hiro> they announce themselves on the list
17:31:10 <hiro> tor-mirrors
17:31:17 <phw> cohosh: i could see mirrors being useful if there was a reliable discovery mechanism but at this point i don't see much value. what am i missing?
17:31:23 <hiro> like "hi I have put in place a new mirror"
17:31:47 <antonela> nice, but what we do with an email in the mailing list? go and update the website?
17:31:51 <hiro> phw that's the position many have and that's why we aren't accepting mirrors atm
17:32:10 <phw> what's your opinion, hiro?
17:32:23 <hiro> antonela: I go and add them to a list and the website gets pushed
17:32:34 <cohosh> phw: if you are new and download tor browser from some random site and then later learn why that is bad, you can check the list of trusted mirrors to see if you downloaded one from a known trusted source or not
17:32:41 <hiro> phw, arma has also the complete opposite position, that would be let's accept all the mirrors
17:33:17 <cohosh> also there are reasons other than tp.o censorship for having mirrors
17:33:22 <hiro> because value > risk
17:33:39 <phw> right, when i think of mirrors, i'm primarily thinking about distributing load
17:33:50 <antonela> hiro: exactly, so you are maintaining the mirrors list rn
17:34:09 <hiro> antonela: rn nope :) we aren't adding mirrors
17:34:18 <antonela> hiro right ha
17:34:28 <cohosh> we could have a rotating anti-censorship team task to google "download tor browser" and find out about possibly malicious or untrusted mirrors
17:34:33 <hiro> phw cohosh: if this discussion is too long we can think about it and talk via email or open a ticket
17:34:46 <gaba> opening a ticket and discussing there would be good
17:34:51 <cohosh> sounds good
17:34:54 <gaba> so we open up to other people
17:35:21 <phw> i worry that there's a lot of nuance in teaching people what to watch out for. in general, we want everybody to download binaries only from our website. except in these few other cases, like mirrors, that are complicated to explain.
17:35:34 <phw> agreed
17:36:30 * phw checks the pad to see if there's a new announcement
17:36:56 <gaba> one thing that would be good is for mirrors to have a clear text on how people can verify their own download
17:36:57 <phw> ok, let's check the needs_review section
17:37:50 <hiro> gaba: they would have that if they are a mirror of our website.
17:37:55 <gaba> yes
17:38:08 <hiro> but they could kind of tamper with the keys for example
17:38:46 <cohosh> my reviews are mostly covered
17:38:55 <cohosh> i'll check in with emmapeel and arlo about #31384
17:39:43 <phw> hiro: right.. the risk of that may be low but the damage is very high.
17:40:37 <phw> dcf1: i saw sina's bridge go offline for ~15 minutes some time after you filed #31890. i wonder if he already updated but again forgot to update the ticket :)
17:40:53 <phw> anyway, i'll make sure to update bridgedb's moat
17:41:41 <phw> do we have somebody for arlo's #31391?
17:41:57 <phw> looks like you're set as reviewer, cohosh?
17:42:36 <phw> hiro: do you need any reviews for gettor?
17:43:16 <hiro> not at the moment, I am currently migrating the host. Reg bridgedb nagios check,  would you like me add it?
17:43:40 <phw> hiro: yes, please! #12802 has been haunting me for months
17:43:55 <hiro> can the script be part of bridgedb repository?
17:44:05 <hiro> so I will make a PR to that
17:44:24 <phw> hiro: sounds good. there's a scripts/ directory that may make for a good home for this script.
17:44:30 <hiro> yep
17:44:35 <phw> thanks
17:45:16 <cohosh> whew lost connection
17:45:25 <cohosh> phw: i already reviewed that ticket
17:45:32 <phw> cohosh: gotcha
17:46:00 <phw> i think we covered everything for today. anything else?
17:46:48 <phw> #endmeeting