14:06:22 #startmeeting 14:06:22 Meeting started Wed Jul 8 14:06:22 2015 UTC. The chair is aagbsn. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:06:22 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:06:25 aha :) 14:06:28 thanks, aagbsn 14:06:32 who is present? 14:06:32 Sounds good. (This is Roya) 14:06:35 (for the meeting bot) 14:06:42 * qbi 14:06:42 hello Broya 14:06:49 * isabela 14:06:52 * karsten is present 14:06:54 * sbs is here 14:07:02 * phw 14:07:10 ** 14:07:25 l 14:07:45 okay, pasting the agenda from my email: 14:07:55 - Introductions: - what are we working on, - what are we planning to do in the near future, - what would we want to learn more about, - what are most pressing needs that we would appreciate help with, - do people think they'd better fit into one of the other teams, - etc. 14:08:06 I guess I'll start. 14:08:37 I'm working on Metrics, CollecTor, ExoneraTor, Globe, and metrics-lib. 14:08:54 this started in 2009 when I worked on an early version of Metrics, 14:09:08 err, not Globe, but Onionoo. 14:09:24 CollecTor was formerly part of Metrics and is now an own service. 14:09:31 same with ExoneraTor. 14:09:42 Onionoo is the backend behind services like Atlas and Globe, 14:09:55 and metrics-lib is a parsing library that avoids duplicating too much code in the other things. 14:10:25 I'm planning to keep maintaining these codebases and keep running these services. 14:10:44 I'd want to learn more about what other people are working on or would want to work on. 14:11:08 and I'd like to have feedback on this team thing, nor or after the meeting. 14:11:16 that's enough from me. who wants to go next? 14:11:37 I can go 14:11:42 please do 14:13:15 I'm Aaron. I'm working on the Tor Bandwidth Authority system - identifying and fixing some currently ongoing issues. I'm working on graphing the vote data from the Directory Authorities that run Bandwidth Authorities, and trying to coax some existing Directory Authority operators to pair up with another Bandwidth Authority operator. 14:13:37 much needed work. thanks for doing that! 14:13:39 I could use some help figuring out where vote parsing should happen, and where the data might go, and what sort of useful cases people might have 14:14:23 * karsten makes a note about that for a later discussion phase, or for after the meeting. 14:14:24 and, my own computing infrastructure is too pokey to crunch all the descriptors, so I might want to borrow or rent some faster equipment 14:14:56 ok, any questions - or save for later, otherwise the next is free to go 14:15:13 ok I can go 14:15:21 aagbsn: I'd say save for later. 14:15:26 hellais: please go 14:15:39 aagbsn: I have a response for you there, but let's discuss that later. 14:15:41 I am Arturo Filastò, in the measurement realm I work on oONI 14:15:43 *OONI 14:16:10 most of my time has been occupied lately to setup the data collection pipeline and designing a HTTP API to access the collected data 14:16:14 FIN 14:17:04 sounds related to my fun with CollecTor. 14:17:27 hellais: speaking of ooni, 14:17:36 which parts overlap most with measurements in the tor network? 14:17:45 were there plans to scan bridges? 14:18:09 and were there plans to re-use the scanning code for things like bwauth? 14:18:12 we also scan bridges, that is implemented as part of our bridge reachability study 14:18:30 we have vantage points in Iran, China, Russia and Ukraine 14:18:46 that study is ongoing? 14:18:59 I wrote some scanning code for ooni, I think we didn't merge it and I had some hope that meejah might build some similar components into txtorcon natively, and perhaps a bit cleaner 14:19:04 but unfortunately due to poor maintainance of the infrastrcture the probes need to be updated with more up to date software and the new bridges added 14:19:19 of the bridges we currently monitor a lot of them have gone offline 14:19:22 * karsten realizes he's now asking questions after telling aagbsn to move questions to the discussion phase... 14:19:35 the pluggable transport used in china is no longer working and other mess like that 14:20:08 ok. 14:20:51 let's continue with introductions and continue with questions/discussion afterwards. :) 14:20:58 i can go next. 14:21:03 please do 14:21:08 this is philipp winter. i'm working on exitmap (looks for bad relays), sybilhunter (looks for sybils), and zoossh (parsing library for Tor data). i'm mostly interested in finding and removing bad actors from tor, but i also worked with Broya on censorship measurement. i could use help with operations, i.e., interacting with community and handing blocklists to the dirauth operators. 14:21:26 in the near future, i'll spend some more time crunching archived data and looking for sybils and anomalies. 14:21:50 that's it, i think. 14:22:11 * karsten makes a note about help with operations. 14:22:44 okay, who's next? 14:22:50 I can go 14:22:55 please 14:23:21 My name is Jens Kubieziel. I'm volunteering and am part of TorServers. 14:24:12 Last weeks I struggled to get my own work finished and hadn't time for anything else. In the next weeks I'll working on fixing parts of TorServers infrastructre and hope to help weasel more. 14:24:27 sounds great! 14:24:28 Currently I'm not so into measurement things 14:24:38 done. 14:24:52 thanks. 14:24:55 I can go next. 14:24:59 please do 14:25:12 This is Roya Ensafi. I have been designing side channels to detect Tor reachability. Just recently I started working on  adding censorship events and other events to the user graphs at https://metrics.torproject.org/.  Here is the steps I plan to do: I want to understand https://gitweb.torproject.org/metrics-web.git/, then write a patch to add an event to a graph. Then I will email the list, presenting the code patch. 14:25:50 oh, great. we should talk more about that graph thing later. 14:27:01 I'm currently working on testing and improving Onionoo and metrics-lib. In the future I plan to continue this effort. In particular reducing memory requirements of Onionoo, improving document storage, metrics-lib, and documentation for future operators. Although if my assistance could be used elsewhere I would be happy to assist. 14:27:34 your help with onionoo and metrics-lib is much appreciated! 14:27:52 I'm just slow at responding to ticket comments these days. sorry for that. 14:27:53 np 14:28:39 it happens, gives me more time to do the testing and such 14:29:04 if you're still around after the meeting, let's briefly talk about onionoo/metrics-lib, if you like. 14:29:15 ok 14:29:19 cool 14:29:33 okay, who didn't introduce themselves yet? sbs? anyone else? 14:29:58 I'm Simone Basso, and I'm part of the OONI team 14:30:23 Specifically I work on a library to do mobile measurements, including OONI measurements but also 14:30:37 other measurements such as network performance stuff 14:30:43 done 14:31:37 cool. quick remark: maybe you know about torperf? that's for measuring performance in the tor network. 14:31:57 sbs: uhm, no actually I don't know about it 14:32:00 * sbs googling 14:32:03 it's not clean code at all, but I think we're going to make it better in the near future. including measuring hidden-service performance. 14:32:12 look at metrics.torproject.org, performance graphs. 14:32:27 any other introductions? 14:32:48 isabela is tor's PM and mostly watching, I think. 14:33:12 I think that means we're done with introdutions. 14:33:28 my notes: 14:33:29 - where can aagbsn parse votes 14:33:29 - help phw interact better with community and handing blocklists to dirauth ops 14:33:32 - roya wants to add a graph to Metrics 14:33:49 hellais, qbi, leeroy, sbs: anything we can help with that we should add to that list? 14:34:14 karsten: if somebody could help us out with maintaining the bridge reachability probes that would be epic 14:34:28 yes 14:34:36 hellais: okay, let's add that as item 4. 14:34:42 ^^ (me watching and can suppport wherever is needed) 14:34:43 it's not a lot of work it's mainly a matter of ensuring that the disks don't run out of space, that the pluggable transports we use to submit reports are not blocked and that the VPSs are renrewed 14:35:08 I can provide whoever wants to do that with a bitcoin wallet to do the last point 14:35:30 okay, let's start with that discussion point then. 14:35:59 isabela: thanks for being around. :) 14:36:20 I can't think of anything to add 14:36:57 hellais: how much does that person need to know ooni details? 14:37:36 karsten: I would say not much, they basically have to run pip install ooniprobe --upgrade from time to time 14:38:07 hellais: is there more to read about bridge reachability scanning, or are results from past scans available? 14:38:12 and when we need to update the list of bridges copy a text file to the box 14:38:38 karsten: Choke Point Project did this visualization: https://beta.chokepointproject.net/measurements/tor-bridge-reachability 14:39:12 neat. 14:39:26 you can access the raw reports from: http://api.ooni.io/ in the Iran, China, Russia, Ukraine sections 14:39:49 I wonder, if you don't find somebody here now, would you want to ask on one of the mailing lists? 14:40:04 the CPP visualization is not up to date with the data collected since we restored the pipeline, but it should be a matter of them pointing it to the new location 14:40:14 I guess you'll want to find somebody who's already known in the tor community? 14:40:31 karsten: yes absolutely, we don't want a random person doing this 14:40:37 since we are giving them private tor bridges 14:40:42 yes. 14:40:49 how about tor-assistants@? 14:41:00 that could be an option 14:41:22 and if you don't find anybody, let's discuss again in a week or two? 14:41:48 btw, we should more generally talk about finding operators for the many services we have. 14:41:49 hellais: Do you have any kind of monitoring etc. installed? 14:41:56 karsten: yes 14:41:57 hellais: Maybe we can discuss this later. 14:42:06 * karsten would be curious, too. 14:42:31 because, maybe part of finding operators is to make operating easier. 14:42:36 qbi: vasilis is working on setting up monitoring for the probes run by trusted probe operators with logstash and ideally this would be also used for the bridge reachability study 14:43:05 but my experience with automated stuff is that it will eventually break and there needs to be somebody that cares about that particular project to fix it 14:43:16 OK 14:43:19 scrollback goto -30 14:43:24 oops. 14:43:27 :) 14:43:37 let's move to the next item? 14:43:43 - where can aagbsn parse votes 14:43:49 aagbsn: what do you need? 14:44:22 a torproject.org VM or an EC2 instance? 14:44:26 I wanted to know if building an API endpoint to ask for - bw values (or not) from the bwauths, for a relay, and a range of time, was something that would be useful 14:45:02 who would use that API? 14:45:05 or, if there is a better/easier way to produce useful graphs for relay operators about how each bwauth votes, over time 14:45:26 I would use it to see if there is a pattern between relays that are humming along nicely and then suddenly becoming unmeasured 14:45:47 but also to provide feedback to show whether patches to bwauths are helpful and improving 14:45:54 my experience is that it makes sense to do such things locally first and look if results are useful. 14:45:55 I think it would be useful to ensure network-health 14:46:16 and then spend more effort on automating things and make them more widely available. 14:46:23 probably most useful to the maintainers, monitors of bwauth 14:46:41 also would like to understand how geographic diversity affects measurements 14:46:50 and other types of questions people might want to answer 14:46:55 that are related to bwauth 14:47:09 how about you crunch some numbers on EC2 and produce results to discuss with bwauth ops and relay ops? 14:47:20 where numbers are votes, I guess. 14:47:53 and if we think that these results should be available long-term, we talk about adding things to Metrics and/or Onionoo? 14:47:55 ok - for graphing things, I had considered using client-side graphing libraries like d3 - i guess a fair number of our users despise javascript, though 14:47:58 a dedicated graphing api means more eyes from the community and can be separate from the source of data 14:48:33 aagbsn: I think d3 is perfectly fine for prototyping. 14:48:47 but rendering all the graphs for all the relays is expensive, and I'm not much familiar with libraries in python (or javascript) to graph things in either case - so pointers or protips are welcome 14:49:25 karsten: is onionoo also a repository of historical data? 14:49:41 it is. it provides bandwidth histories, among others. 14:49:42 the major concern I have with relying on onionoo is that it's too specific to the relay, bwauths deserve their own special treatment 14:50:05 I had imagined that each relay would have a graph 2ith ~4 lines on it, one for each bwauth values 14:50:22 leeroy: it could be onionoo for per-relay data and metrics for aggregate network data. 14:50:53 and, 'unmeasured' would be represented by a gap in the graph 14:50:57 aagbsn: such things are very hard to predict without having the data. I usually try graphing them and then think about better graphs. 14:51:09 ok. 14:51:17 aagbsn: I would probably extract some data to .csv and then use R to explore then. 14:51:20 them* 14:51:26 i have a script to produce data, it just runs very slowwwly on my little laptop - it does produce csv 14:51:29 there's alot more useful information that can be derived from a bwauth specific-solution, and it's extensibility won't be limited by onionoo 14:51:50 but I think a month of data is probably fine, that will take a few hours/day to crunch 14:51:54 onionoo integration would come once there are no interesting research questions left. 14:52:16 ok - let's consider this a prototype - I can use github for the time being 14:52:19 do you need anything for that, or is your little laptop good enough? 14:52:46 it is ok for now 14:53:05 ok. let us know when that's not the case anymore. I don't know exactly what resources we can make available, but I can ask. 14:53:26 should we move on to the next item? 14:53:33 (and procesing the full archive will hopefully be a 1 time task) 14:53:37 (I'm trying to keep these meetings at 60 minutes max.) 14:53:44 ok 14:53:45 hopefully :) 14:53:46 if you need a data source or document store for the bwauth data I could use metrics-lib to do that if you like 14:54:42 java would be faster than python parsing using stem 14:54:58 and it would give leeroy an excuse to optimize the code even more. :) 14:55:03 ;) 14:55:06 :D yes 14:55:34 okay, I think we have one topic we should discuss here and one after the meeting. 14:55:48 Broya: let's talk more about the graph after the meeting. 14:55:55 sure :) 14:56:07 phw: how can we help you interact better with the community and with handing blocklists to dirauth ops? 14:57:16 while phw is thinking, how about we meet again next week? 14:57:40 we could probably switch to bi-weekly at some point, but maybe weekly makes sense to get this started. 14:57:42 karsten: Do you have a specific date in mind? 14:57:44 it would be great to have another responsive person on bad-relays@. it's mostly roger and me. 14:58:09 qbi: same date, same time? (I admit, I didn't say that I was looking for a regular meeting time.) 14:58:25 having another person to interact with the dirauth folks is more difficult because it requires trust. 14:58:27 karsten: This would fit. 14:58:48 phw: you added more people to that list lately, right? 14:59:14 yep. some people are interested in that space and i'm trying to get them more involved. 14:59:18 karsten: good plan. 14:59:43 phw: also, it might be that you won't find somebody today. would you want to ask for help on tor-assistants@? 15:00:07 including giving them a place to learn more about confirming complaints sent to bad-relays@? 15:00:48 i have the feeling that everybody on tor-assistants is already overloaded. that's why i'm trying to get more people from the broader community involved. 15:01:33 good point. 15:01:50 it's not super urgent, so we can worry about that later. let's see how it goes. 15:01:59 maybe tor-relays@? those folks care a lot about the network. 15:02:13 let's pick this up again next time, ok? 15:02:36 sounds good. and yes, tor-relays is probably a great place to ask. 15:02:43 okay, should we end this meeting? 15:02:50 almost under 60 minutes. 15:03:10 if you have any suggestions for the next meeting, please let me know. 15:03:38 thanks everyone for attending! 15:03:52 aagbsn: can you turn off the bot, please? :) 15:04:52 #endmeeting