13:59:22 #startmeeting metrics team 13:59:22 Meeting started Thu Feb 18 13:59:22 2016 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:22 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:59:30 who's here for the meeting? 13:59:53 hi karsten 13:59:55 me (hi!) 14:00:05 as usual, let's put items on the agenda in the next few minutes. 14:00:10 hi dcf2 and thms_! 14:00:39 suppose I'm here. Just sitting back and listening, or reading in this case. 14:01:10 Grobbler: sounds good. hello. 14:03:38 4 topics so far, let's start in 30 sec. 14:04:09 okay, 14:04:14 * Valencia preparation (karsten) 14:04:28 Let's talk about things that we'd like to get done in Valencia 1.5 weeks after. There's no need to prepare topics enough to discuss them tomorrow, we just need bullet points. We'll have a full week after tomorrow's meeting to think about these topics to make the most out of Valencia. Like brainstorming. Oh, and even if you won't be in Valencia, feel free to suggest topics anyway, and the rest of us 14:04:35 might discuss them in Valencia and get back with some results. 14:04:50 I have a short list of things I'd like to get done, let me start with that. 14:05:32 1) Metrics team, what worked well, what can we improve; how can we team up more? should we resurrect the task exchange? etc. 14:05:57 2) Berlin roadmap (stickies and PDF), funding proposals, etc. 14:06:33 3) Metrics website, JavaScript, Big Datas, more contributors to Metrics, help with maintaining content. 14:07:05 4) help with developing and operating Metrics-related services and libraries, writing scripts to monitor them, improving release processes, etc. 14:07:45 I'm still thinking whether to suggest technical things like ed25519 identities, or if that should be something ad hoc for the hack days. 14:07:59 that's my list. what topics would others want to see in valencia? 14:08:45 I don't have a list other than ad hoc hacking. 14:09:11 heh, that's most fun, of course. 14:10:53 waiting another minute for topic suggestions.. 14:11:50 otherwise I'd say send suggestions to metrics-team@ as they come up. 14:12:02 okay, moving on to 14:12:07 * Lower/upper bounds on users-by-transport-by-country, https://trac.torproject.org/projects/tor/ticket/10218#comment:20 14:12:19 I assume that's dcf2's? 14:12:30 Yeah. 14:12:45 I just wanted to bring it up so other metrics people know what is going on. 14:12:54 good idea. 14:13:03 should I provide more data? 14:13:10 kersten had a great idea to estimate user by pt by country by figuring lower and upper bounds from the users by country and users by pt data. 14:13:28 And the ticket has some pictures of what it looks like. 14:13:37 asn_ might be interested in this. 14:13:53 No, I don't think I need more data. 14:13:58 ok. 14:14:22 thanks for trying this out! 14:14:23 I had done something similar for just the meek bridges in just another ticket, so I can probably synthesize my own if I need it. 14:14:40 That's all. 14:15:28 we should probably talk more about this in valencia with the other usual suspects. 14:16:01 maybe we can put graphs on metrics. we'd probably have to extend the database schema for it. 14:16:24 ok. 14:16:39 The most-used transports seem to have tighter ranges (which makes sense when bridges run multiple transports), but we could have graphs showing ranges for each day. 14:16:40 let's talk about item 4 first, because it's related: 14:18:05 Recent releases of Tor Browser introduced a lot of new obfs4 bridges. 14:18:22 8 of them. 14:18:24 ah 14:18:24 * default Tor Browser bridges not reporting statistics 14:18:45 and they are not reporting statistics? 14:19:05 Some of them had "PublishServerDescriptor 0" because we were running tests to see how soon they get blocked and were trying to keep their addresses from leaking through BridgeDB. 14:19:17 I think 7/8 had "PublishServerDescriptor 0". 14:19:22 ugh 14:19:36 A side effect of "PublishServerDescriptor 0" is that bridges don't report user statistics. 14:19:39 so, we have this discussion on trac. 14:19:52 here's a new idea: could bridgedb have a blacklist of bridges that it doesn't give out? 14:20:05 I didn't realize that we would be losing so much statistics, I'm sorry for that. 14:20:06 that would be much faster to implement. 14:20:24 It turns out there is a workaround and the bridges can report statistics while still having the other properties we want. 14:20:33 Now 4/8 bridges are reporting statistics, and 14:21:04 I'll ask the operator of the other 4 to start once I hear back that the first 4 didn't get added to BridgeDB. 14:21:20 I think it already had an effect on the obfs4 graph: 14:21:25 https://metrics.torproject.org/userstats-bridge-transport.html?start=2015-11-20&end=2016-02-18&transport=obfs3&transport=obfs4&transport=meek&transport=%3COR%3E 14:21:30 (Last couple of days.) 14:22:04 so, I tried hunting down bridge operators a year or so back for the same reason. 14:22:11 karsten: to answer your question, yes bridgedb could not hand out certain fingerprints, though I suppose that would be hard to keep in sync. 14:22:34 and I think they did change their configs back then. but as we see, this problem comes up again. 14:22:44 I don't think we have a problem in general with default bridges not reporting statistics, it's just these new obfs4 ones and that was my fault. 14:22:59 No, I think this time it's because I asked them to. 14:23:07 ok. 14:23:19 isis purged all the non-reporting ones some time back I think, because we had enough alternatives. 14:23:37 And the other 4 remaining non-reporting ones should be reporting within a couple of days. 14:24:16 Honestly I don't know if any action is required on this. 14:24:38 ok. works for me. 14:24:39 The workaround is fine for what we're doing. For all the other bridges it doesn't matter if they're in BridgeDB or not. 14:25:04 I'm just thinking of the future when other projects or sub-projects might want to distribute their own default bridges, 14:25:17 or someone wants to test a new bridge distribution strategy, or something, 14:25:42 and then it might be nice to separate some bridges from bridgedb while still reporting statistics. 14:26:21 I realized that we are doing something like that by accident, as some of the bridges are listening on multiple ports (through iptables forwarding) and of course only one of those ports is being reported in the descriptor. 14:27:12 so, proceed with the ticket (and its near-duplicates), but no rush, right? 14:27:31 So today, if someone needed a workaround and had extra IPs, they could have a non-BridgeDB IP:port forward to a BridgeDB IP:port, where the non-BridgeDB IP:Port would simulate having a non-public but still statistics-reporting bridge. 14:27:36 Right. 14:28:39 ok! 14:28:52 (P.S. there wre other existing obfs4 bridges, besides these new 8, that were reporting all along.) 14:30:02 moving on to 14:30:04 * trying to get analytics project in shape for an introduction to potential users (thms) 14:30:19 (thanks for the updates, dcf2!) 14:30:44 oh, yes, not much to say really. I’m trying, but I can’t promise 14:31:16 strange, dark, frustrating adventures in java land… 14:31:55 fun with java generics 14:32:24 that, and undocumented libraries, and other stuff 14:33:01 okay, anything we can help with today? 14:33:18 no, thanks 14:33:57 ok. and we ran out of topics early. anything else we should talk about? (this is the last meeting before valencia!) 14:35:59 alright, let's not forget about metrics-team@ for discussions before valencia, and then let's talk more in valencia! 14:36:21 thanks for attending, thms and dcf2! 14:36:27 #endmeeting