16:59:57 <phw> #startmeeting anti-censorship weekly checkin 2019-07-25
16:59:57 <MeetBot> Meeting started Thu Jul 25 16:59:57 2019 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:57 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:03 <phw> hi friends o/
17:00:04 * cohosh is here but also in another meeting
17:01:08 <phw> lol, the front page of bamsoftware.com
17:01:28 <phw> ok, we have one discussion item
17:01:38 <phw> our pad is here: https://pad.riseup.net/p/tor-censorship-2019-keep
17:02:06 <cohosh> ok nvm, leaving other meeting since we have 2 people already there
17:02:15 * arma1 ha's at the frontpage too
17:02:30 <cohosh> lol
17:02:52 <phw> you may remember from stockholm that we wanted some kind of table that encodes what's necessary to make tor work in a given country or AS
17:03:10 <phw> this table would help tor browser do the right thing, with minimal user interaction
17:03:27 <phw> so the user doesn't need to figure out that you need, say, obfs4 in country X
17:04:01 <phw> i started with a simple csv file over here: https://dip.torproject.org/anti-censorship/state-of-censorship/tree/master
17:04:22 <phw> here are a bunch of preliminary fields that we may want in this table: https://dip.torproject.org/anti-censorship/state-of-censorship/blob/master/README.md
17:05:43 <phw> the idea is to update this table as we learn about what works and doesn't work in a given place, and have the git history reflect this knowledge.
17:06:11 <dcf1> seems like a good place to start
17:06:27 <dcf1> Maybe add a field for the torproject.org web site / download page.
17:06:30 <phw> this is quite similar to past efforts, like the metrics timeline.  and these past efforts are ideal to bootstrap this table.
17:06:44 <phw> good idea dcf1
17:07:00 <cohosh> cool! not sure how we'd do this in a table but do we want to communicate some kind of priority ordering on these?
17:07:21 <cohosh> like please try obfs4 first before you try meek for example
17:07:55 <phw> cohosh: that's a good point.  i suppose we could have a global preference but we may also want a per-country preference
17:09:20 <phw> if you can think of other fields, please let me know and we'll work it in
17:10:06 <phw> i just added another discussion point while nobody was looking
17:10:37 <phw> so, i deployed our work-in-progress bridgedb metrics patch, to see how we can improve it
17:12:01 <phw> i think we should add a "filter" component that can abort requests based on, say, the user agent
17:12:10 <dcf1> What does it mean "crawling"?
17:12:44 <phw> dcf1: most requests that bridgedb sees are coming from bots
17:12:53 <dcf1> ok
17:13:17 <cohosh> and you know that from the user agent?
17:14:01 <phw> cohosh: yes, the crawling activity is all done over tor.  you can see the requests cycling through exit relays.
17:14:11 <phw> ...which makes them easy to link together.
17:14:31 <phw> also, the crawler is requesting obfs2, which is no longer supported by bridgedb.
17:14:55 <dcf1> one interesting experiment is to block that particular crawler, then see if/when they actually notice.
17:15:12 <dcf1> maybe returning blank or false results is better than blocking outright.
17:15:23 <phw> i assume a non-trivial amount of effort went into this given that they get the vast majority of captchas right.
17:15:38 <cohosh> ah lol requesting bridges through tor...
17:15:53 <dcf1> Right, but obfs2 may indicate that they are not paying attention.
17:16:08 <dcf1> You know how it is, you spend a couple of months working intensively on something, then kinda forget about it.
17:16:11 <phw> cohosh: that's another issue.. bridgedb has code to detect "proxy requests" but as far as i can tell, it never worked, so the tor exit relays are treated like any other ip address.
17:16:35 <dcf1> phw: oh drat, I always thought that Tor clients got their own segregated bucket. At least that was the idea.
17:16:48 <phw> dcf1: returning blank results is a great idea.  given the recent bridgedb breakage, that shouldn't be particularly surprising either.
17:17:25 <phw> dcf1: right, that was the idea.  there's an ancient bulk-exitlist in bridgedb that was still being considered but it's several years old
17:17:34 <phw> the "automatically fetch new tor exit relays every 3 hours" component was broken
17:17:50 <phw> i'm working on fixing it.
17:17:56 <dcf1> This work you're doing on BridgeDB is so valuable, just wanted to say.
17:18:58 <phw> i hope it'll be worth it.  the number of bots is disillusioning.
17:19:10 <phw> next week i hope to have some numbers from the metrics branch for you.
17:20:16 <phw> ok, that's it from my side.  just wanted to keep y'all updated and i appreciate the suggestions!
17:20:56 * cohosh agrees, this is really good work!
17:21:05 <phw> any other impromptu announcements/discussions?
17:21:30 <dcf1> Yes let's put the snowflake infra blocking on the record somewhat.
17:21:55 <dcf1> There are 3 tickets, which I think are all the same issue: #31230, #31231, #31100
17:22:30 <cohosh> #31100 is slightly different, it was filed before this was a problem and has some other unrelated fixes in it
17:22:44 <dcf1> Short description: a few days ago, it seems that every *.bamsoftware.com URL is blacklisted by the Google Safe Browsing service.
17:23:11 <dcf1> This affects the in-browser proxies which make HTTPS requests to https://snowflake-broker.bamsoftware.com/, and WebSocket connections to wss://snowflake.bamsoftware.com/.
17:23:37 <dcf1> arma1 sent email yesterday to some people at Google who might be able to say why they are being blocked, but no response yet.
17:24:00 <dcf1> The key question is whether the block is related to Snowflake itself, or to something else hosted on a *.bamsoftware.com domain.
17:24:22 <dcf1> If it's not related to Snowflake, then all we need to do is get a new domain name separate from bamsoftware.com for Snowflake stuff.
17:24:51 <dcf1> If it's related to Snowflake, then we need to avoid putting Snowflake-related infra on torproject.org, because that may get all of torproject.org blocked just like bamsoftware.com is currently.
17:25:17 <dcf1> ok that's the summary.
17:25:57 <dcf1> Currently there's 24 snowflakes at https://snowflake-broker.bamsoftware.com/debug, about half of which look like browser proxies.
17:26:12 <dcf1> When I checked yesterday there were only 9 or so, mostly proxy-go IIRC.
17:26:48 <phw> google's anti-abuse research team lead, Elie Bursztein, may be helpful here.  i don't know him personally but i know people who have co-authored papers with him and may be able to get us in touch.
17:27:38 <dcf1> I don't mind being a stubborn cuss and having bamsoftware.com blocked for a while, but I want to fix the snowflake outage.
17:28:09 <arlolra> dcf1: any reason to suspect it isn't snowflake related?
17:28:26 <cohosh> it seems.. likely it's the zipbomb stuff right?
17:29:07 <dcf1> That's my best guess, but who knows. It's weird that they block every subdomain, but maybe that's standard for Safe Browsing.
17:29:14 <phw> on my "maliciousness" scale, i would rate zipbombs >> snowflake
17:30:16 <dcf1> Right, but you may be making the mistake of thinking about it as a rational person.
17:30:25 <cohosh> heh, otoh google didn't particularly like participating in meek in the end
17:30:35 <cohosh> and we do use their stun servers by default
17:30:48 <cohosh> and we may have just gotten the stun servers blocked in china
17:30:55 <dcf1> Yeah, it could be some weird misunderstanding or something. I don't want to jump to any conclusions.
17:31:03 <phw> "they got our stun server blocked, now we'll get their website blocked.  that'll show 'em"
17:31:33 <phw> but yes, that's a good point
17:31:42 <cohosh> so it seems like the best option is try to wait to hear back before possibly migrating to a torproject.net domain?
17:31:43 <dcf1> The short term-fix suggested of putting proxies through the domain-fronted URL, now sounds like it may not work, because it seems there's also a problem with the WebSocket to snowflake.bamsoftware.com.
17:32:41 <dcf1> The most certain easy-to-implement workaround, as I see it, is to buy some domain that is neither bamsoftware.com nor torproject.org and point that at the infra servers.
17:33:12 <dcf1> We're not exactly locked into it forever, and the Let's Encrypt stuff makes it easy for TLS to staart working once the DNS records exist.
17:33:44 <dcf1> That requires someone to buy the name, somehow coordinate access to it, etc.
17:34:01 <cohosh> i have a domain i'm not really using at the moment
17:34:53 <cohosh> but i wouldn't mind getting another temporary one for this either
17:34:56 <phw> setting up a separate domain sounds sounds like a good idea to me.  maybe even as a long-term solution, so we don't suffer from the side effects of relying on bamsoftware or torproject.
17:34:58 <dcf1> cohosh: you're right, #31100 is some other thing that is being complicated by the Safe Browsing thing.
17:35:25 * cohosh thinks of snow related puns
17:36:46 <cohosh> snowflake.best is currently 3.95CAD/year on namecheap
17:37:07 <arlolra> why not just use tpo?
17:37:30 <dcf1> That's the problem with these new TLDs, they all look like either malware hosting or Fediverse instances :)
17:37:56 <dcf1> arlolra: the fear is that if bamsoftware.com is blocked because of Snowflake per se, it may result in torproject.org getting blocked if we move things there.
17:38:09 <arlolra> right, that would be the point though
17:38:20 <arlolra> is tpo really not safe for browsing
17:38:28 <dcf1> I don't think it's particularly likely, but likely enough to worry about.
17:38:35 <cohosh> we're also not sure the sysadmin team will be willing to point a tpo domain to a host they don't control
17:38:57 <arlolra> i see
17:39:20 <cohosh> omg snowflake.world is even cheaper
17:39:42 <cohosh> snowflake.rocks
17:40:37 <dcf1> maybe we ought to make a ticket for this. There could be better ways than getting a new domain, but it's the most expedient path I see.
17:41:40 <cohosh> ok sounds good
17:41:41 <phw> i'll file a ticket once we're done
17:41:58 <phw> anything else wrt snowflake?
17:42:56 <phw> ok, let's move on to everyone's "needs help with" section
17:43:47 <phw> #31100 needs review
17:44:25 <phw> and so does #27385
17:44:45 <dcf1> cohosh is marked as reviewer for #27385
17:44:50 <phw> oh, right
17:44:53 <cohosh> i can take a look at #27385
17:45:07 <dcf1> #31100 isn't such a big patch, I can do it.
17:45:11 <cohosh> if anyone else wants to as well feel free
17:45:16 <phw> #31170 also needs review
17:45:37 <dcf1> #31170 is more like "needs info" or "needs a decision"
17:46:10 <dcf1> IMO it also needs new icons in consultation with the UX team, unless I miss something about the features available to webextensions.
17:46:29 <dcf1> well, I guess there is a branch to review there too :)
17:47:15 <cohosh> we could have one of us review the branch and also ping antonela?
17:48:23 <arlolra> sign me up
17:49:11 <phw> looks like we're done for today!  any last words?
17:49:35 <phw> #endmeeting