16:02:10 #startmeeting SponsorR 16:02:10 Meeting started Tue Jan 20 16:02:10 2015 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:10 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:02:14 so hello 16:02:21 i see dgoulet, armadev and karsten. so that's good. 16:02:35 and welcome back from the sponsorr meeting. 16:02:42 let's start with short status reports? 16:03:01 sure. 16:03:12 ah hello ohmygodel 16:03:16 hello asn 16:03:23 over the past week I've mainly been doing reviews for other little-t-tor stuff. 16:03:26 has the meeting started ? 16:03:30 ohmygodel: just now. 16:03:33 ok good 16:03:34 you didn't miss anything. 16:03:35 hi ohmygodel. are rob and paul coming, too? 16:03:46 not sure about them 16:04:01 ok. we can send them backlog if they come late. 16:04:11 good idea 16:04:25 i've also read ohmygodel statistics aggregation schemes and commented on them. since then ohmygodel has posted another scheme that I haven't yet read. 16:04:26 * karsten stops interrupting asn 16:04:55 i also worked on some hsdir bugs (#14149 etc.) but I actually should work #8243 which is more important and harder. 16:05:06 and that's that for sponsorr really. 16:05:18 karsten: you wann go next, and then we have all the people who attended the real life meeting? :) 16:05:23 sure. 16:05:36 so, I worked more on the tech report where we're extrapolating hidserv-stats. 16:05:44 latest version is here: https://people.torproject.org/~karsten/volatile/extrapolating-hidserv-stats-2015-01-17.pdf 16:05:51 yes, this looks great. 16:06:00 and I made a few graphs for slides. 16:06:01 thanks. :) 16:06:08 it's not complete yet though. 16:06:18 but let's discuss that under next steps. 16:06:20 one topic for later discussion wrt that is the blog post that should accompany it :) 16:06:23 yep 16:06:32 yes, blog post sounds good. 16:06:43 okay, that ends my status report. did a lot of non-R stuff lately. 16:06:52 great thx 16:07:00 ok who wants to go next? 16:07:05 i can 16:07:06 ohmygodel: please! 16:07:17 i spent last week at the sponsor r meeting 16:07:39 a few things got accomplished broadly 16:07:55 (more than me worked on these things) 16:08:21 1. there was a “challenge problem” to help investigators from the department of justice child obscenities section 16:08:34 (aka DOJ CEOS) 16:09:03 to figure out what child abuse is being conducted via Tor 16:09:20 that went very well, and they seemed pretty happy with the ideas they were presented 16:09:45 dgoulet can talk more about that 16:09:50 aha 16:10:09 I think my last email on tor-internal explains it a bit eheh 16:10:15 2. i talked to the Sponsor R program manager (chris white) about future directions for the NRL people (in collaboration with the Tor people) 16:10:25 ok yeah dgoulet 16:10:46 he seemed very supportive of all of the options i described to him 16:11:10 including trying to implement secure bandwidth measurement 16:11:26 developing private statistics aggregation protocols 16:11:54 and working on HS protocol changes to improve performance 16:12:23 so that is good news - we seem to have some options for the next few months 16:12:41 are these new plans, as opposed to what was written in a contract half a year ago? 16:12:50 do we need to change contracts for this? 16:12:53 3. i discussed with roger and paul and dgoulet which of those options we actually want to pursue 16:12:58 we should discuss those during discussion 16:13:04 no need to change contracts; our deliverables were very broad on purpose 16:13:04 no change of contract 16:13:09 ok 16:13:18 all of these things were in the proposal in some form 16:13:29 sounds good. 16:13:42 ohmygodel: yes, discussion phase should definitely include future plans :) 16:13:42 but you still really need the support of the PM as you go along 16:14:00 oh and 16:14:21 4. i proposed another refinement of the statistics aggregation protocols (AnonStats3) 16:14:26 ok done 16:14:37 thanks! 16:14:46 dgoulet: you wanna go next? 16:14:50 sure 16:15:41 not much apart from attending SponsorR hackfest last week... not sure what I can say more about that since seems everything was said eheh 16:16:06 ok that's good. 16:16:21 ok, so let's move to discussion phase? 16:16:30 armadev: any updates from you? 16:16:34 i can add a few points 16:16:37 yes armadev 16:16:52 i mainly spent last week making sure tor stays integrated with the broader sponsorR program (the other groups) 16:17:13 i'm glad david was there. there's another week in april, and i'll need to leave on that tuesday afternoon, 16:17:24 so we need more people there to believe that talking to david is like talking to tor 16:17:57 in july the week is actually four weeks, so one of the decisions we'll need to make in april, based on how things look then, is how many people to send for how long a time in july. 16:18:27 yes that's going to be interesting 16:18:47 i think the valencia dev meeting might be a nice place to discuss this :) 16:18:49 i also had a meeting with jeff moss (black hat) and some other folks, and the week before with the facebook guy, and it looks like we should put together a coalition for getting more 'good' hidden services in the world 16:18:59 s/black hat/defcon/ 16:19:02 i agree. 16:19:20 ok, discussion time 16:19:23 ok thx 16:19:30 so let's moev to the discussion phase . 16:19:43 i think the big topic here is "wtf we do the upcoming months" 16:20:14 there are more short-term stuff to discuss too like "what should we do now with the stats pdf that karsten has prepared. we should probably push it to the community." 16:20:27 yes, we should discuss how to finalize that. 16:20:29 but maybe we should start with "wtf we do the upcoming months" and see where it takes us? 16:20:38 or what do you think? 16:20:42 including things like writing a blog post, updating dir-spec.txt, updating metrics-lib/Stem, etc. 16:20:49 yes, sounds good! 16:20:52 ok 16:20:59 +1 16:21:16 ok, so dgoulet and roger has sent some sekrit emails 16:21:16 * dgoulet is fighting a massive headache so sorry if I'm a bit quiet :S 16:21:25 with what sponsorr likes and what we should be doing in the future 16:21:33 it looks like the general categories are the same 16:22:01 that is, statistics, performance, bugfixes, and some security and "better undersatnding of HSes". 16:22:20 should we walk over each category and discuss possible things to do? 16:22:25 or that's not the best use of our time? 16:22:32 and we should do this over the mailing list in our own pace? 16:23:10 it's a fine plan, I think. 16:23:15 which one? 16:23:29 walking over each category and discussing possible things to do. 16:23:31 ok. 16:23:46 let's try to not go depth-first :) 16:23:57 so, statistics, 16:24:01 yes 16:24:04 ok so high level for statistics 16:24:09 ohmygodel: yes 16:24:14 a) finalize hidserv-stats we already started, 16:24:23 b) add more stats (that other tech report), 16:24:31 c) discuss AnonStats[1-3], 16:24:33 what else? 16:24:49 can c) be develop private statistics aggregation ? 16:25:03 sure. 16:25:06 the outcome is hopefully some code that works 16:25:11 for april? 16:25:23 work where? 16:25:32 i think I prefer the generic term "R&D" here 16:25:40 because I don't know how long the *R* part will take. 16:25:54 and the D part depends on R :) 16:26:03 for example, george danezis has also been talking to me about his own private statistics aggregation ideas 16:26:38 are we defining goals today? or can we just say let's make good progress on these things? 16:26:45 true 16:27:18 i think it is not necessary that we have a deployed aggregate statistics thing in april 16:27:26 but it might turn out, in april, that we really want one in july 16:27:35 it may not be necessary 16:27:39 but i think its possible 16:27:48 and it is necessary for pretty much any of the remaining interesting statistics 16:28:00 nickm: finally in american time, I can actually follow up on trac :) 16:28:20 i actually think there are plenty of interesting ones that don't require the aggregation. but yes. 16:28:35 mvdan: :) 16:28:46 (i think they are interesting because statistics about things we think we understand are wins, either because they confirm our understanding or because they contradict it.) 16:29:03 ok. let's leave it at "make good progress in private statistics aggregation" and figure it out in the upcoming weeks? 16:29:16 sounds good to me, asn. 16:29:21 also, the statistics we have currently are not enabled by default. 16:29:28 its just that almost everything remaining at an HSDir and anything at an IP is ruled out 16:29:43 i don't mind that much, but it certainly influences the quality of our results. 16:29:59 karsten: btw, i'm happy that the new RP-traffic graphs don't have any weird spikes. 16:30:08 karsten: because it means that the quality of our results is not that terrible. 16:30:28 asn: yes, the quality is surprisingly good. 16:30:29 nickm: I still don't understand how could we recurse tor_rmdir into a symlink to a directory 16:30:34 karsten: for example, if HS traffic was *much more* than we currently think, we would _maybe_ have seen some sort of spike over multiple days 16:30:58 right. 16:31:08 nickm: oh, stat follows links and lstat doesn't. duh. 16:31:13 ok, so "statistics" category is done for now. 16:31:15 asn: sounds like we should put 'turn that on by default' on our roadmap for this quarter 16:31:20 e.g. once tor 0.2.7 forks 16:31:30 armadev: or "decide if we should turn that on by default" :) 16:31:40 but yes 16:31:41 armadev: and enable by default in 0.2.7 and not in 0.2.6? 16:31:52 something like that. timing is up for discussion. 16:31:56 ok 16:32:04 on my list already. 16:32:08 we could do it in 0.2.6 with a consensus param to change our mind. many options. 16:32:15 ye 16:32:21 ok. category "statistics" busted. 16:32:22 let's move on. 16:32:33 let's move to "2) Performance and correctness" 16:32:40 that's more towards what dgoulet has been doing. 16:32:51 dgoulet: where do you see this going over the next months? 16:32:58 yeah so I think there are two parts here we can discuss 16:32:59 now that you are also aware of the appetite of the sponsor? 16:33:03 did I mention how cool it is to write down results in tech reports? 16:33:16 karsten: i agree. 16:33:16 dgoulet: ^ 16:33:37 1) HS performance in terms of code and bugs (which we have bunch of tickets) 16:33:38 david from subgraph told me some weeks ago "Tor has been doing all this crazy research stuff and it's only in weird trac tickets. I wish the whole world knew how much research Tor is doing." 16:33:40 2) The HS protocol itself 16:33:49 asn: full ack. 16:33:52 asn: so true 16:34:07 we had 1 report in 2014. /me stops interrupting 16:34:22 dgoulet: aha 16:34:23 so in terms of performance, I would really start with having a network testing kind of "framework" 16:34:28 right 16:34:29 in which we can test scenarios 16:34:41 i think that's also what armadev is looking for. and it's tied to sponsorS too. 16:34:55 we now have a framework to collect the data we need (tracing) we need a way to run scenarios that is more than just chutney on my kvm 16:34:58 asn: yes 16:35:10 so I would say in the next weeks, that would be a good goal 16:35:25 .oO(so the data is collected through tracing, not control port events?) 16:36:00 because in the past, the sponsorr roadmap had a fair chunk of controller changes to allow this kind of testing infrastructure. 16:36:02 asn: yes tracing because we go a bit deeper and very fast paste like all cells ;) 16:36:17 btw robgjansen just messaged me on hangouts 16:36:21 dgoulet: ack 16:36:22 hes having a firewall issue at nrl 16:36:26 his update is 16:36:29 use tor! 16:36:29 “can you just tell people that i checked in, my updates are basically the same as dgoulet in that we spent time trying to get shadow+lttng working” 16:36:34 asn: maybe we should figure that out indeed 16:36:41 ohmygodel: ack 16:36:46 yeah, about that: “well, tor browser is hanging on trying to connect to a bridge” 16:36:55 :) 16:36:56 ohmygodel: say hi to rob. hope he can make it next week. 16:37:01 asn: control port events we want but armadev proposed a very intersting one that I want a do, control event that dumps the content of an hs desc 16:37:12 ah 16:37:14 ok 16:37:19 we already have HS_DESC events. 16:37:22 seems kind of connected. 16:37:30 yup it is 16:37:47 the idea there is the 'hs health monitor', but one step farther -- are the descriptors at each hsdir the same? or is one older? or is one hsdir not having the descriptor? etc 16:37:50 not very difficult and something some SponsorR team can use also for their crawler 16:38:03 ok 16:38:10 yep. it's something that should totally be done first on a test network, but also then reusable on a real network for comparison. 16:38:35 i imagine a modified tor client could pretty easily ask all the hsdirs, rather than picking one randomly 16:38:36 ok, so that's a bit more like the "HS testing" category 16:38:41 which might produce some "performance" tickets. 16:38:54 yes and correctess indeed 16:38:56 yep. some of those tickets i filed in september but they're just sitting there, perhaps because nobody understood them. 16:39:12 i guess some time i should walk through those tickets to help people understand the ideas behind them 16:39:22 armadev: are they SponsorR tagged? 16:39:27 yes 16:39:30 ok 16:39:37 we will have to walk through these soon. 16:39:55 so I think we have good goals for that performance + correctness part 16:39:59 and maybe add more tickets that could be performed as part of SponsorR. 16:40:04 dgoulet: seems OK for now. 16:40:14 let's move to the next category 16:40:15 dgoulet: are you in contact with nickm about the broader testing framework plan? 16:40:27 and, are you the right person for that 16:40:28 armadev: ofc, we started the "plan" for that in Boston :) 16:40:47 meaning, is it smartest for us to say "oh i can ignore that, david and nick have it" 16:41:14 I think in the next weeks it is reasonable for you to assume that yes :) 16:41:19 great 16:41:22 ok great 16:41:26 so next category is "Security" 16:41:35 which is a pretty big category for HS. 16:41:42 we should choose which stuff can be done as part of SPonsorR. 16:42:10 Maybe the more SponsorR side of "security" are changes that will influence more people to set up "good" HSes? 16:42:13 like the HSDir bug. 16:42:18 eeehm 16:42:26 i meant, the "randomize HSDirs" task. 16:42:35 or the "make it harder to be come HSDir" thing. 16:42:50 or I'm not sure. but I can certainly look into this category and come up with a few useful tasks. 16:42:50 armadev can maybe provide sponsor-r-appropriate justification for that task 16:42:57 so one thing that would be nice here is to make bandwidth measurement more secure 16:43:03 and accurate 16:43:04 yes! 16:43:07 that's true. 16:43:09 this applies to sponsor r for three reasons 16:43:13 hm. i had been thinking of that as part of the 'statistics' section. 16:43:22 1. we normalize our measurements by probability, but load might not exactly match that 16:43:23 yeah I think that could fit in sponsorr with a justification that it's related to stats 16:43:31 armadev: love it. 16:43:58 secure bandwidth measurement turns out to be critical to all of these "each relay votes about the statistic proportional to its size" designs. 16:44:01 ohmygodel: could you talk a bit abou what this "secure bw measurement" project would entail? 16:44:02 2. to collect anonymous statistics, we need to prevent malicious actors from sending garbage, and one good idea is to give everybody a “weight” that is their measured bw contribution 16:44:19 asn: is any of the HSDir thing you mentionned above also fits for 224 or it's just lost work when 224 is implemented 16:44:22 yes right armadev 16:44:32 asn: they're working on a research paper design for it currently. also, i hope it replaces the bwauth scripts. 16:44:45 3. better bandwidth measurement might improve load balancing, which could improve HS performance 16:44:56 (and the future existence of this research paper is why we have so far avoided messing with the broken bwauths much) 16:44:59 how much of the remaining work is *R* and how much is *D*? 16:45:18 approx 16:45:24 4 weeks R 16:45:39 D…. less clear to me 16:45:50 ok.i guess we need to read the paper to figure htis out. 16:45:52 one piece of a BW measurement system that uses relays to measure relays 16:46:01 is that they need to report those statistics somewhere 16:46:06 but they need to do it anonymously 16:46:16 where they then need to be aggregated 16:46:19 ohmygodel: isn't peerflow that has new crypto? 16:46:42 ohmygodel: are you implementing it as part of your research paper? 16:46:45 basically it can use many of the protocols that have been suggested for this 16:46:58 well research-level implementing 16:47:05 ok 16:47:13 my point is that making progress on secure stats aggregation 16:47:22 wait, and peerflow uses relays to measure relays? 16:47:26 would also serve to make progress on this 16:47:29 asn: yes 16:47:42 so it's a little-t-tor patch, not an external script ? 16:47:43 or is it both? 16:47:58 i think rob is patching tor 16:48:05 i expect it's both 16:48:19 so both dirauth-side, and relay-side. 16:48:22 yep 16:48:24 "exciting" 16:48:31 dirauths may be left out 16:48:40 they already take simple v3bw files from the bwauths 16:48:43 the dirauth side needs to learn what new numbers to vote 16:48:44 that division can be preserved 16:48:47 yep 16:49:07 so it is relay-side and ???-side 16:49:12 where we get to decide on ??? 16:49:15 fair enough. 16:49:22 and it uses cryptography in fascinating ways? 16:49:23 we call it bwauths, but yes 16:49:39 asn: im just using AnonStats2 16:49:56 so AnonStats2 is a primitive inside peerflow? 16:49:57 it doesnt suffer the problem in this case that i had described to you 16:50:05 ok interesting 16:50:12 so it has some crypto. 16:50:21 but to answer dgoulet's question from far above: any improvements we make to the hsdir design should be compatible with proposal 224. it would be foolish to do work and then plan to throw it away later. 16:50:22 yes 16:50:24 but work that we put in this will also benefit the statistics aggregation thing. and the opposite. 16:50:39 *yawns*, good morning world 16:50:40 armadev: yes 16:50:43 atagar: hello 16:50:52 dgoulet: in particular, sponsorR is happy for us to evaluate proposed design changes to see how they will mess with our statistics, understanding, etc. 16:51:05 ok, I think the topic of "secure bw measurement" is done for now? 16:51:06 i think that includes looking at proposed design changes for all sorts of security improvements. 16:51:19 ah yes armadev, that was the justification for security you told me last week 16:51:22 ack 16:51:23 to figure out the *D* time we will need to see the paper. is it published? 16:51:23 that i thought was pretty good :-) 16:51:36 for peerflow that is. 16:51:46 asn: submission deadline of 2/23/15 16:51:52 ok 16:52:09 so definitely not to act on now 16:52:12 so I think this is more like a july item, but we can try to do some stuff with it till april too. 16:52:15 but thinking to the future 16:52:17 yes 16:52:18 ok 16:52:23 that's that then. 16:52:28 ohmygodel: will your final paper change quite a bit from the one I have now ? 16:52:38 dgoulet: yes 16:52:49 for example, cover traffic is out and AnonStats2 is in :-) 16:52:56 ohmygodel: ok! 16:53:15 ok, let's call the "security" section as done for now? but we will need to revisit it soon. 16:53:16 * karsten realizes how ohmygodel could guess the 4 weeks this precisely. 16:53:20 a paper deadline!... ;) 16:53:24 haha 16:53:31 ha guilty 16:53:45 there are two more sections I would like to touch which is "better understanding of HSes" and "opt-in HS publishing" 16:54:16 "better understanding of HSes", probably this one is tied to network testing I guess?.. 16:54:19 hm 16:54:22 i think i meant more like 16:54:42 "make it easier and nicer for 'good' people to setup HSes" 16:54:51 ah ok 16:55:01 i wonder what stormy is 16:55:04 like stormy, the sponsor o thing? 16:55:07 yes like stormy 16:55:10 or like encrypted services 16:55:16 or like fixing the SSL CA onion mess. 16:55:39 stormy is a script that sets up a hidden service for you. a blog, or something else. 16:55:41 i'm excited about these stuff (especially the first two), and I'm wondering if SPonsorR would also be excited. 16:56:02 and of course the "opt-in HS publishing" thing also ties to these projects. 16:56:17 yeah opt-in I would say is definitely SponsorR 16:56:20 since it can be used by ahmia etc. to make nice HSes more visible and public. 16:56:27 for opt-in publishing, i was just thinking a torrc option, in the default torrc but commented out, so you can tell some central point about your hs 16:56:32 i wonder what central point this should be 16:56:33 yes 16:56:40 unclear I guess for now. 16:56:49 or maybe it is a flag in your hsdesc, which tells the hsdir to give it out in response to requests? 16:56:57 but should we add "R&D" for this project in the upcoming months? 16:56:59 probably a flag in the hsdesc would be wise anyway 16:57:13 so then later hsdirs can count what fraction of hs's set the flag 16:57:46 well, you already will know how many HSes set the flag (since it's public) 16:57:46 for general hs usability improvements, it is still not clear that it is directly in sponsorR's interest 16:57:58 and if hsdirs publish the number of descs, you have all the necessary numbers to get the fraction. 16:58:09 armadev: ok 16:58:25 but one way to make it more aligned is to have some stats to measure popularity or something, 16:58:32 and then induce a change, and observe the change with those stats. 16:58:47 (and it just happens that the change we induce is to make more legit hidden services exist) 16:59:06 statistics-driven development 16:59:13 heh 16:59:18 :) 16:59:41 ok so. 16:59:52 it's clear we don't have a precise roadmap yet. but we have done some partial enumeration. 16:59:55 how should we move this forward? 16:59:56 * armadev practices his deliverable judo 17:00:32 we can each get a category, and send a [tor-dev] post with more precise deliverables? 17:00:43 and then we can nitpick in each other's category? 17:01:01 sounds like a good idea, each of us breaking down a category 17:01:06 etherpad maybe ? 17:01:07 good start at least 17:01:14 etherpad sounds good. 17:01:21 i have things to add, and i prefer to do collaborative editing via email 17:01:28 ok 17:01:29 i prefer *not* to do 17:01:30 np for me 17:01:35 ok etherpad is fine. 17:01:40 not very community, but it's ok. 17:01:49 well we can post the final draft I guess? 17:01:56 sure 17:02:03 we should be sure that it goes somewhere more long-lasting, once it exists, yes 17:02:09 speaking of people working on this, 17:02:16 are we going to add more people? 17:02:22 yes that's a good question. 17:02:33 much of this stuff has funding from other sources 17:02:34 you should be aware that nickm and andrea are funded in part by this project 17:02:35 sponsor Q for stats 17:02:40 we've had at least 3 people ask if they can get involved. 17:02:43 so don't be too shy about asking them to do items 17:02:49 and the testing framework project also (i forget the sponsor) 17:02:54 S 17:03:19 ok so there a substantial funding behind the items weve discussed working on 17:03:25 there *is substantial 17:03:55 what's the process for discussing to add new people? 17:04:04 email armadev? 17:04:24 i guess so, since the budgeting situation is still quite opaque to us devs. 17:04:32 what are we talking about here? people helping out? or people being funded by this. 17:04:37 the latter. 17:04:40 oh. 17:05:12 yes, that's a budgeting question. i would not be surprised to learn that we don't have any extra funding for new people. we have a lot of plates in the air this year. 17:05:41 it also sounds related to those 50+ mails i have waiting for me over the past month. 17:05:51 :) 17:05:54 ok karsten 17:06:01 let's start by designing the deliverables 17:06:07 and then maybe the budgeting situation will have cleared up slightly 17:06:15 and we can see how other people can fit in the picture? 17:06:30 (who are the three? or is that not public info yet) 17:06:37 virgil was interested. 17:06:38 not really. 17:06:46 ah, now it's 1/3 public. 17:06:47 mttp has been interested. also aagbsn has been intersted. 17:07:27 oh well, then it's four people. I have been thinking about adding phw. 17:07:28 and I also have 1-2 people in mind that would fit in the HS landscape, but I haven't asked if they would want to be involved with SPonsorR. 17:07:46 oh well, and i wanted to speak with donncha :) 17:08:01 lots of people. 17:08:08 as it seems. 17:08:11 tor is popular :) 17:08:13 we definitely can't fund all of the broader community around this stuff. and also we definitely do need to grow and maintain a broader community around this stuff. 17:08:35 i hear that juha will be at sri for some months starting in some months 17:08:42 that's nice. 17:08:57 will he be working on ahmia? 17:09:06 hope so 17:09:07 great 17:09:25 anyway, we can discuss the extra people later I guess... 17:09:32 armadev: there is a (mostly inactive) hs stats tor mailing list 17:09:35 yeah, budget + tasks will help us 17:09:38 asn: sounds good. let's just not forget. 17:09:43 perhaps those people should be invited 17:09:54 ok 17:10:07 ohmygodel: we should start using that mailing list. 17:10:20 “we” this sponsor r group 17:10:27 does it include all the folks on the sri mailing list? if so, we could just switch over 17:10:36 or “we”: the people interested more generally 17:10:53 i believe that it does armadev 17:11:00 "we" the people that paul invited. 17:11:05 but memex-specific stuff, like planning for meetings and making slides, would not be relevant 17:11:06 and I hereby declare https://etherpad.mozilla.org/LDiWZpI1sz-roadmap to be the pad where we do deliverable planning etc. 17:11:56 btw armadev, have you seen that mail that nick sent about project management 17:11:57 great asn 17:12:02 and how all teams should send him our deliverables for hte future? 17:12:07 asn: i am aware of it but have not seen it. 17:12:36 should we do it *real soon now* (where deliverables are going to be very vague), or should we do it in two weeks or so (where deliveerables will be more refined) 17:12:39 four events in a row messed me up good 17:12:40 ? 17:12:45 or you have no idea. 17:12:51 i have no idea. depends what the mail says. 17:12:56 ok 17:13:18 OK guys. WE are already 72 minutes in this madness. 17:13:27 just one thing before everyone leaves: 17:13:28 what do we need to do to wrap this up? 17:13:40 we'd really need some feedback on 17:13:41 https://people.torproject.org/~karsten/volatile/extrapolating-hidserv-stats-2015-01-17.pdf 17:13:46 to finalize that thing. 17:14:07 ok karsten: i will read an send comments today 17:14:10 i'll try to provide feedback rsn. 17:14:13 ohmygodel: thanks! 17:14:20 btw, this week I'll also be busy with uni stuff. 17:14:25 just saying 17:14:28 where are we on the other tech report ? 17:14:33 good question. 17:14:37 is there a plan to publish that ? 17:14:56 we should totally publish that. 17:14:59 and there is 0.2.6 deadline also by the end of this month I think so need to balance sponsorr and code review ehhe 17:15:01 which is the other one? the list of plausible stats to collect? 17:15:07 armadev: yes 17:15:08 yes, armadev. 17:15:25 the "other one" is more unrefined than extrapolating-hidserv-stats-2015-01-17.pdf 17:15:28 seems like all these things should be listed and linked from the sponsorr wiki page, so we know what is coming 17:15:35 but the "other one" is more long term than extrapolating-hidserv-stats-2015-01-17.pdf. 17:16:19 karsten: i imagine that the other tech report will be refined more as part of "(b) add more stats" of the "statistics" section. 17:16:24 did we assign who's going to handle which part of future deliverables? 17:16:30 no. 17:16:38 or was that implicit? I do stats, dgoulet testing, asn security? 17:16:46 sounds good to me. 17:16:55 and we all bug squash when we can? :) 17:16:55 i'm also fine with blending up as the weeks moves on. 17:17:12 dgoulet: uhmmmmm. 17:17:13 do we want to set a firm deadline on when the deliverables should be finalized? 17:17:16 i don't feel like doing this now. 17:17:21 maybe next meeting? 17:17:24 asn: too early I think 17:17:28 let's break everything down 17:17:29 good 17:17:36 for the next meeting 17:17:39 ok 17:18:11 so let's say each of us is a lead in a category and we collaborate along the way like we did, worked really well last quarter :) 17:18:17 ok 17:18:20 yup 17:18:21 sounds good to me. 17:18:24 i'll be around IRC anyway. 17:18:29 so we can adaptively adapt. 17:18:40 much adapt 17:18:40 dynamic dynamism! 17:18:44 synergy! 17:18:45 ok so no decision on the stats tech report 17:18:56 (btw my vote is to just wrap it up and publish it) 17:19:17 what do you mean by "publish it"? 17:19:23 give it a number 17:19:24 what is this plan for a blog post? (a blog post on what?) 17:19:30 armadev: so 17:19:33 and put it in the tech reports on the tor site 17:19:34 I should read it? but yes, I agree that we should publish soon. 17:19:41 erm, I should read it. no ?. 17:19:44 armadev: so we made this extrapolating-hidserv-stats-2015-01-17.pdf and we presented it to SponsorR 17:19:53 armadev: it would be nice, since we made it, to also present it to the community 17:20:04 yes, also because we asked many relay operators to help with this. 17:20:07 armadev: so we could write a small blog post with the gist of our findings, and also give out the pdf for people who want to read it. 17:20:29 sounds good to me. 17:20:34 +1 17:20:43 maybe in that blog post we could have a small section with "we've also been writing this other tech report which is not yet done and will be changed over hte next months, but here it is for now"? 17:20:49 (Patch workshop in 40 minutes.) 17:20:55 and this way we semi-publish the other tech report too? 17:21:03 asn: sure. 17:21:08 or just make the other one good enough and publish it soon enough after 17:21:23 yes or that. 17:21:26 who's editing that other report right now? 17:21:35 no one 17:21:46 okay, so we'll find someone next week? 17:21:47 i had the lock, but I did some trivial changes and released it. 17:21:56 (also merged aaron's changes) 17:22:08 “will be changed over hte next months” ~= s/month/weeks :-) 17:22:19 sure 17:22:27 ok guysssss 17:22:39 i thiiiink we did some progress here. 17:22:44 very much so 17:22:44 thanks for running this meeting, asn! 17:22:44 * armadev starts adding items to the etherpad 17:22:54 ok 17:22:59 let's use the etherpad over the following week 17:23:04 question from rob 17:23:05 “also there is one thing i would like to know: is it worth my time to try to test out the effect of OptimisticData?” 17:23:16 anybody have a response to that ? 17:23:40 (armadev: TvdW is the author of the alternative tor fwiw) 17:24:09 ohmygodel: eeeehhm 17:24:18 ohmygodel: it would certainly be nice to know how much effect on performance it had 17:24:19 ohmygodel: unclear, the HS improvement we see in 0.2.6 is not due because of that since it was not used while measuring 17:24:26 ohmygodel: for normal tor, we graphed the components from torperf, and pointed to the purple layer and said "that is the layer that disappears when you use optimisticdata" 17:24:38 ohmygodel: but i wouldn't say that it's super high prio. 17:24:53 how are we on having a torperf to a hidden service? so we can have those same layers graphed? 17:25:40 ok thx all 17:26:09 armadev: all I know about that is in #1944 17:26:55 yes, we don't have a torperf running right now that measures HS performance. 17:27:33 ok guys wrapping this up 17:27:36 thanks all 17:27:38 #endmeeting