16:59:57 #startmeeting anti-censorship weekly checkin 2019-07-25 16:59:57 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:03 hi friends o/ 17:00:04 * cohosh is here but also in another meeting 17:01:08 lol, the front page of bamsoftware.com 17:01:28 ok, we have one discussion item 17:01:38 our pad is here: https://pad.riseup.net/p/tor-censorship-2019-keep 17:02:06 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 lol 17:02:52 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 this table would help tor browser do the right thing, with minimal user interaction 17:03:27 so the user doesn't need to figure out that you need, say, obfs4 in country X 17:04:01 i started with a simple csv file over here: https://dip.torproject.org/anti-censorship/state-of-censorship/tree/master 17:04:22 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 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 seems like a good place to start 17:06:27 Maybe add a field for the torproject.org web site / download page. 17:06:30 this is quite similar to past efforts, like the metrics timeline. and these past efforts are ideal to bootstrap this table. 17:06:44 good idea dcf1 17:07:00 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 like please try obfs4 first before you try meek for example 17:07:55 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 if you can think of other fields, please let me know and we'll work it in 17:10:06 i just added another discussion point while nobody was looking 17:10:37 so, i deployed our work-in-progress bridgedb metrics patch, to see how we can improve it 17:12:01 i think we should add a "filter" component that can abort requests based on, say, the user agent 17:12:10 What does it mean "crawling"? 17:12:44 dcf1: most requests that bridgedb sees are coming from bots 17:12:53 ok 17:13:17 and you know that from the user agent? 17:14:01 cohosh: yes, the crawling activity is all done over tor. you can see the requests cycling through exit relays. 17:14:11 ...which makes them easy to link together. 17:14:31 also, the crawler is requesting obfs2, which is no longer supported by bridgedb. 17:14:55 one interesting experiment is to block that particular crawler, then see if/when they actually notice. 17:15:12 maybe returning blank or false results is better than blocking outright. 17:15:23 i assume a non-trivial amount of effort went into this given that they get the vast majority of captchas right. 17:15:38 ah lol requesting bridges through tor... 17:15:53 Right, but obfs2 may indicate that they are not paying attention. 17:16:08 You know how it is, you spend a couple of months working intensively on something, then kinda forget about it. 17:16:11 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 phw: oh drat, I always thought that Tor clients got their own segregated bucket. At least that was the idea. 17:16:48 dcf1: returning blank results is a great idea. given the recent bridgedb breakage, that shouldn't be particularly surprising either. 17:17:25 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 the "automatically fetch new tor exit relays every 3 hours" component was broken 17:17:50 i'm working on fixing it. 17:17:56 This work you're doing on BridgeDB is so valuable, just wanted to say. 17:18:58 i hope it'll be worth it. the number of bots is disillusioning. 17:19:10 next week i hope to have some numbers from the metrics branch for you. 17:20:16 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 any other impromptu announcements/discussions? 17:21:30 Yes let's put the snowflake infra blocking on the record somewhat. 17:21:55 There are 3 tickets, which I think are all the same issue: #31230, #31231, #31100 17:22:30 #31100 is slightly different, it was filed before this was a problem and has some other unrelated fixes in it 17:22:44 Short description: a few days ago, it seems that every *.bamsoftware.com URL is blacklisted by the Google Safe Browsing service. 17:23:11 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 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 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 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 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 ok that's the summary. 17:25:57 Currently there's 24 snowflakes at https://snowflake-broker.bamsoftware.com/debug, about half of which look like browser proxies. 17:26:12 When I checked yesterday there were only 9 or so, mostly proxy-go IIRC. 17:26:48 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 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 dcf1: any reason to suspect it isn't snowflake related? 17:28:26 it seems.. likely it's the zipbomb stuff right? 17:29:07 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 on my "maliciousness" scale, i would rate zipbombs >> snowflake 17:30:16 Right, but you may be making the mistake of thinking about it as a rational person. 17:30:25 heh, otoh google didn't particularly like participating in meek in the end 17:30:35 and we do use their stun servers by default 17:30:48 and we may have just gotten the stun servers blocked in china 17:30:55 Yeah, it could be some weird misunderstanding or something. I don't want to jump to any conclusions. 17:31:03 "they got our stun server blocked, now we'll get their website blocked. that'll show 'em" 17:31:33 but yes, that's a good point 17:31:42 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 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 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 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 That requires someone to buy the name, somehow coordinate access to it, etc. 17:34:01 i have a domain i'm not really using at the moment 17:34:53 but i wouldn't mind getting another temporary one for this either 17:34:56 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 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 snowflake.best is currently 3.95CAD/year on namecheap 17:37:07 why not just use tpo? 17:37:30 That's the problem with these new TLDs, they all look like either malware hosting or Fediverse instances :) 17:37:56 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 right, that would be the point though 17:38:20 is tpo really not safe for browsing 17:38:28 I don't think it's particularly likely, but likely enough to worry about. 17:38:35 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 i see 17:39:20 omg snowflake.world is even cheaper 17:39:42 snowflake.rocks 17:40:37 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 ok sounds good 17:41:41 i'll file a ticket once we're done 17:41:58 anything else wrt snowflake? 17:42:56 ok, let's move on to everyone's "needs help with" section 17:43:47 #31100 needs review 17:44:25 and so does #27385 17:44:45 cohosh is marked as reviewer for #27385 17:44:50 oh, right 17:44:53 i can take a look at #27385 17:45:07 #31100 isn't such a big patch, I can do it. 17:45:11 if anyone else wants to as well feel free 17:45:16 #31170 also needs review 17:45:37 #31170 is more like "needs info" or "needs a decision" 17:46:10 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 well, I guess there is a branch to review there too :) 17:47:15 we could have one of us review the branch and also ping antonela? 17:48:23 sign me up 17:49:11 looks like we're done for today! any last words? 17:49:35 #endmeeting