18:00:51 <cohosh> #startmeeting anti-censorship checkin 2020-02-20
18:00:51 <MeetBot> Meeting started Thu Feb 20 18:00:51 2020 UTC.  The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:51 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:00 <gaba> thanks cohosh! o/
18:01:07 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
18:01:38 <cohosh> okay starting with discussion, the one about translations was from last week so i removed it
18:01:52 <dcf1> oops i misfiled my link
18:01:52 <cohosh> the next one is about binary size, was that also from last week or do we have an update on that?
18:02:40 <cohosh> oh it's removed alright so no discussion/announcements today?
18:02:59 <gaba> because it was from last week
18:03:06 <cohosh> ah thanks gaba
18:03:31 <gaba> it seems we may not have discussion items?
18:03:33 <cohosh> dcf1: anything you want to discuss re: snowflake and turbotunnel?
18:04:00 <dcf1> I just wrote up some first impressions at https://trac.torproject.org/projects/tor/ticket/33336#comment:11
18:04:32 <dcf1> I'm going to recommend the experimental bundles to amiableclarity and maybe whatever cypherpunks are reading tor-talk.
18:04:52 <cohosh> nice!
18:05:25 <cohosh> this is making the snowflake dogfood much tastier
18:05:45 <dcf1> yeah it's somewhat usable, though still not as nice as I would like.
18:06:10 * cohosh nods
18:06:23 <dcf1> Occasionally your proxy disappears and then you may get stuck for several minutes with no feedback, or even get tor into the dreaded "No running bridges" state.
18:06:59 <cohosh> the multiplexing should help with that
18:07:27 <cohosh> maybe we should look into the no running bridges problem as well
18:07:30 <dcf1> yeah at least now it is plausible, though occasionally frustrating, to run a Snowflake browser all day
18:07:31 <cohosh> i don't think we have a ticket for that
18:08:14 <dcf1> I think there are many tickets that mention it but it's never been gotten to the bottom of
18:08:27 <dcf1> This experience with Snowflake is definitely not the first I've seen it
18:09:04 <dcf1> Even without pluggable transports, I occasionally need to briefly activate obfs4 then deactivate it, to get tor to reset something internally and start working again.
18:09:22 <cohosh> hmm interesting, i did not know about the problem with obfs4
18:09:45 <dcf1> It's not a problem with obfs4. That's just a conveniently available option that changes tor's state somehow.
18:09:55 <cohosh> i knew there was an issue with meek and local addresses (0.0.3.0) discussed at one point
18:09:58 <cohosh> ah ok
18:10:00 * phw wonders if ahf has any insight regarding the above
18:10:05 <dcf1> Makes tor change its guard context from "default" to "bridges" or something.
18:10:31 * arma2 catches up on backlog
18:10:57 <dcf1> Here's one comment on "No running bridges" (it turned out to be a false lead in that case, but there are links to others)
18:11:00 <dcf1> https://trac.torproject.org/projects/tor/ticket/28717#comment:11
18:12:14 <arma2> the 'no running bridges' thing happens, i believe, because tor marks your first hop down if a circuit build fails before it gets its 'created' response. and that's smart for relays, and maybe smart for obfs4 style bridges, and definitely not smart for the hack where you have one bridge line that is secretly many bridges.
18:12:27 <dcf1> yeah it seems to me that #11301 was never really fixed
18:12:58 <dcf1> "Sometimes, after this problem has happened once, tor will cease building circuits even if the network remains available." certainly describes it
18:13:16 <arma2> in theory tor is supposed to, when it gets a new stream request and all its guards/bridges/whatevers are down, mark them as retriable and give it another go. but i bet it does not do this reliably.
18:13:43 <dcf1> Anyway I don't think this is specifically related to the turbotunnel changes, except that the pluggable transport can now run long enough for the problem to become visible sometimes
18:14:00 <arma2> my first thought is to argue for a flag or config option or something that says "this is not the kind of bridge that you can mark as being unreachable. just don't do it, tor.'
18:14:24 <cohosh> right
18:14:40 <dcf1> mhmm. thanks for the insight, arma2.
18:14:56 <cohosh> i'm trying to track down that ticket dcf1 linked once that talked about strategies for using multiple local addresses?
18:15:00 <dcf1> I've never been able to characterize the problem enough to make a useful bug report.
18:15:01 <cohosh> i think it was a meek ticket
18:15:07 <arma2> and it would apply to meek and to snowflake, because those are the ones that use the "one bridge is secretly many bridges" hack
18:16:36 <arma2> though, hm. we might want to instead replace it with...something...that would let tor realize that things are really not working.
18:16:39 <dcf1> this may be something we can hack around in the short term by increasing some timeout threshold in tor or something?
18:17:49 <dcf1> snowflake-client would signal a fatal error by closing its SOCKS connection, but I think tor is timing out or something earlier than that.
18:17:59 <cohosh> i am also curious about this timeout that seems to happen. specifically what is it and where does it live
18:18:09 <arma2> it would be the "when do you give up on a circuit that is being built" parameter if so.
18:18:17 <cohosh> i kept running into it in #29206
18:18:47 <arma2> periodically tor looks at all its pending circuits, and gives up on the ones that have been pending building for too long
18:18:48 <dcf1> cohosh: is #10429 the ticket you meant about multiple local addresses?
18:18:55 <cohosh> dcf1: yes, thanks!
18:19:06 <arma2> and if a circuit it just gave up on never even made it to the first hop, it takes special action to blame that first hop
18:19:30 <arma2> the goal is so it can rotate to a new entry guard if its current guard is being faily
18:19:33 <dcf1> i see
18:19:45 * ahf reads
18:20:06 <dcf1> I can see this happening with turbotunnel, even though technically tor doesn't see the circuit construction failure except by timeout.
18:20:12 <arma2> and for bridges, if you have 10 obfs4 bridges, this is a solid feature still. you want to avoid even trying the ones that were failing.
18:20:20 <dcf1> That is, as long as proxies are reliable, you can switch between them and tor never even knows about it.
18:20:48 <dcf1> But when you hit a snag and there's a delay of a few minutes, then probably tor times out its circuit, then immediately tries to create a new circuit
18:20:52 <arma2> yeah. from tor's perspective, it will be like "la la, not enough preemptive circuits, time to make a new one. woah, the new one failed -- and it's the bridge's fault!"
18:20:54 <cohosh> dcf1: maybe this is tor browser's socks proxy timeout then?
18:20:58 <ahf> phw: nope, don't have a good answer to that one :-/
18:21:18 <dcf1> Then, because there's there's still no available proxy, this new circuit construction fails at the early stage, leading to the aforementioned special behavior
18:21:43 <cohosh> ah i see
18:22:15 <arma2> yep
18:22:23 <dcf1> so yes, maybe we can ameliorate the situation by tweaking some parameters in tor. It would also help if we could find out why such a large fraaction of snowflake proxies seem to just not work. I think cohosh had a ticket about that.
18:22:39 <cohosh> yeah i have some ongoing measurements
18:22:47 <cohosh> honestly, it seems to be doing a bit better lately
18:23:03 <arma2> yep. i would suggest two hacks on the tor side: (a) loud logging when tor gives up on a first hop. so you know when tor made that choice and what choice it was. (b) a toggle switch to make tor never actually give up on the thing.
18:23:08 <dcf1> #32545
18:23:30 <arma2> people wouldn't want to turn (b) on for normal use, because it would have bad side effects for all your non-snowflake use. but it would help in debugging this issue.
18:24:22 <arma2> cohosh: speaking of snowflakes that don't work. do snowflakes check if they can reach the bridge, before advertising themselves as usable? i ask because i saw 45 snowflakes in china, where the bridge is blocked.
18:24:31 <cohosh> arma2: yes they do
18:24:34 <arma2> great
18:24:48 <cohosh> they don't poll if they can't reach the bridge
18:25:03 <cohosh> that's actually how we found out about the recent bridge failure lol
18:25:12 <cohosh> but there's something else going on as well
18:25:12 <arma2> good stuff
18:25:25 <cohosh> i am hoping to write up some results this week
18:25:29 <arma2> dcf1: ok. i am finally taking a break from this nsf proposal (and handing it to cohosh),
18:25:46 <arma2> so i will aim to do up my two hacks and give them to you in the next day or two (ha, famous last words)
18:25:50 <arma2> and you can see if they make you happier
18:26:15 <dcf1> sure arma2 thanks, if you give me something I will try it.
18:26:28 <cohosh> let's make a ticket for it so we can track what works
18:26:33 <arma2> it will be in the form of a diff on tor source code. which version of tor do you like?
18:26:40 <cohosh> i'm sure many people would be interested in this
18:27:05 <dcf1> 0.4.3.2-alpha is the version in tor-browser-build that I used
18:27:21 <arma2> sounds good
18:28:03 <dcf1> thanks for the discussion everyone
18:28:09 <cohosh> thanks
18:28:38 <cohosh> okay should we move on with needs help with?
18:29:01 <cohosh> i might be the only one in need of reviews
18:29:07 <cohosh> i can ping hiro about that later
18:29:15 <arma2> (dcf1: also, for normal tor relays, they auto recover after a few hours, because the new consensus resets their "are they working" state. so there is automatic forgiveness built in, which bridges don't get.)
18:30:15 <dcf1> cohosh: are you looking for any feedback on #32938?
18:30:32 <cohosh> dcf1: not yet, i'll have something for next week
18:30:37 <dcf1> ok
18:30:37 <cohosh> unless you have some feedback to give now
18:30:43 <cohosh> on the general idea
18:30:49 <cohosh> that is welcome ofc
18:31:02 <hiro> cohosh
18:31:07 <hiro> I have that in my radar for today
18:31:08 <cohosh> hiro: hey!
18:31:12 <hiro> I am going to do it tonight
18:31:25 <cohosh> ok, thanks! i have a few gettor reviews, i can add you as reviewer for them
18:32:19 <cohosh> alright, anything else?
18:32:43 <cohosh> i'll end the meeting in a minute if no
18:33:34 <cohosh> okay thanks everyone
18:33:37 <cohosh> #endmeeting