15:04:29 #startmeeting SponsorR 15:04:29 Meeting started Tue Mar 10 15:04:29 2015 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:29 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:04:34 hello all 15:04:41 can I have a headcount? 15:04:45 here! 15:04:50 here! 15:04:57 yo 15:05:04 here! 15:05:08 hi 15:05:30 epic 15:05:43 and a combination of roger/nick seems to be around too 15:05:52 ok, so welcome to the sponsorr meeting 15:05:59 i imagine that we will spend less time briefing up today 15:06:03 and more time strategizing for the future 15:06:09 since we do plenty of the former during the dev meeting 15:06:26 * nickm is here too 15:06:44 i don't have much to report from the past 3-4 days. i was mainly thinking of statistics that we could do. and non-statistics tasks that I could do. 15:06:51 but we can handle this during the discussion phase 15:06:58 anyone has a status report? 15:07:09 yo. 15:07:10 karsten: i'm curious how the metrics integration stuff are going, if they are. 15:07:24 nickm: want to do a status report first? 15:07:31 or should I respond to asn? 15:07:35 I've been rereading the aggregation designs. #1 would be easy to do, especially if it's a separate thing. 15:07:44 karsten: IRC rules; let's all talk at once. :) 15:07:49 heh 15:08:06 * karsten lets nickm finish 15:08:17 I don't know that I can get aggregation design 1 done in March, unless people really really want me to, and somebody tells me in excruciating detail how to do blind ed25519 signatures 15:08:17 nickm: separate thing even on the relay side? 15:08:27 y 15:08:47 like a separet software that relay ops would have to use? 15:08:55 that communicates with StatsAuths? 15:09:29 That's the idea. It could eventually be distributed as part of Tor, and we could have the thing that launches tor launch that too. 15:09:37 ack 15:09:37 but doing this in the tor process is IMO nuts 15:09:44 ack 15:09:59 woah. meeting. i will read backlog and then be here. 15:10:07 cool nickm 15:10:12 ok nickm. we can discuss this some more later. 15:10:15 ack 15:10:15 i would be interested in helping you with those signatures 15:10:30 anyone else who did anything interesting the past few days? 15:10:39 asn: well, to answer your question, 15:10:48 I looked at the two things you and dgoulet found, 15:11:02 and I think both need better documentation, but at least they are not bugs. 15:11:10 thanks for the review, by the way! 15:11:13 ack 15:11:20 good 15:11:20 peer reviewing that was fun 15:11:29 glad to hear! 15:11:59 (that's all from me re: status report) 15:12:07 nothing for me to report 15:12:08 what is left, after the documentation gets added? 15:12:14 to integrate it to the website? 15:12:27 to integrate the graphs to the metrics website, that is. 15:12:28 move the code to metrics-web.git, 15:12:34 deploy on yatei, 15:12:44 add some html, some R. 15:12:56 well, for the R part, decide what graphs to show. 15:13:17 ok sounds good 15:13:20 not a crazy amount of work altogether. 15:13:24 keep me in the loop if you need more help. 15:13:28 ok, anyone else? 15:13:34 or should we move to discussion phase? 15:13:35 yes, I'll ask for feedback on graphs, I think. 15:13:40 me? 15:13:43 syverson: yes please 15:13:58 i have some things to report. or at least topics to make sure we cover. 15:14:09 armadev: ok. you are in the queue. 15:14:10 Not too much not discussed at dev meeting. Worked on paper w/ Griffin. 15:14:32 In process got Juha to agree to include PGP field in JSON. 15:14:45 ( syverson: I added a note about oour guard lifetime discussion in #8240) 15:14:48 So this should make such onion services more amenable to indexing. 15:15:14 Also ohmygodel and I sighed up for the DARPA Brandeis proposers day. 15:15:19 you mean to the "here are my information" JSON that HSes can put on their web path? 15:15:33 Not exactly sponsor R of course, but should end up being related. 15:16:01 It should be listed in the files when one searches ahmia. 15:16:10 That's about it. 15:16:11 ack 15:16:12 thx 15:16:18 armadev: please 15:16:55 a) i should get isabela on the sri mailing list. i'll mail phil about that shortly. does isa have an @tp.o address? if not we should fix that too. 15:17:13 b) did ya'll see the mail from phil asking for input for the monthly report? is somebody on that? 15:17:20 Yes. 15:17:34 yes i will handle that on the tor side. 15:17:35 But I'm not the person you probably need a yes from. 15:17:44 will have something today 15:17:54 c) paul asked me about the may 'privacy' panel that darpa is thinking about. it is more of an ethics panel it seems. i had a phone call with them a few weeks ago to help them brainstorm directions. 15:18:01 karsten: is there meant to be a line for 'other' or 0.2.6 on https://metrics.torproject.org/versions.png ? 15:18:12 i encouraged them to pick some actual difficult decisions that they've faced in practice, and those would be a core of a nice discussion about how to ethically handle data. 15:18:20 qwerty1: I'll look after this meeting. 15:18:31 they none the less want to continue calling it a 'privacy' panel though, for reasons i haven't pushed on. 15:18:39 Is this a closed meeting? Can others attend? Who can I ask? 15:19:11 syverson: brian is the one coordinating it i believe. feel free to reach out. also, now that i think of it, ryan was supposed to send us a draft list of questions a week or two ago. 15:19:23 i should follow up there and see if it happened and i'm out of the loop, or if it got dropped. 15:19:24 armadev: I dont have @tp.o email 15:19:45 Brian Sandberg I assume. And which Ryan? 15:19:56 isabela: ah 15:19:59 isabela: did you get your pgp key signed at valencia? 15:20:01 d) i had a nice chat last week with pde about his "let's encrypt" scaling plan, one option of which is deploying hundreds of thousands of hidden services. this seems related to SponsorR. 15:20:04 isabela: you will need to open a trac ticket for this 15:20:10 isabela: see for example this one https://trac.torproject.org/projects/tor/ticket/10113 15:20:15 isabela: for the information required 15:20:21 asn: tx will do 15:20:35 Yawning: yes for isabela@riseup.net email only 15:20:35 re (d), pde wrote up notes here: https://trac.torproject.org/projects/tor/wiki/org/meetings/2015WinterDevMeeting/Notes/SecureServerRouting 15:20:43 I have ideas about that. 15:20:45 I should reply. 15:20:55 Will pde mind if I reply on tor-dev? 15:21:01 isabela: that's fine, just need to have a signed key for the process 15:21:13 armadev: will read 15:21:20 nickm: he will not mind 15:21:35 armadev: lets encrypt sounds very cool 15:21:42 ok, those were my items a-d. it seems they've stirred up some further discussion, which we can do in the discussion phase. 15:21:53 it sounds like tor could really use short-circuited onion services 15:22:06 ack 15:22:08 yes, lots of folks want that 15:22:10 let's move to discussion phase 15:22:26 is this where we talk about random onion service stuff including R, or just R 15:22:34 do you people have specific topics to discuss? please list them up. 15:23:07 Yawning: I think it's mainly about R, but you can also mention random onion service stuff and if it's too offtopic we will disucss them later 15:23:09 Is it useful for me to try to hack up a stats aggregation thing in march? by april 15? How useful? 15:23:14 - the “top down” plan were writing 15:23:21 * isabela has an update on random onion service stuff - I will coordinate with folks to set up a bi-weekly meeting for onion services dev community as a follow up from valencia 15:23:31 - implementing anonstats 15:23:45 nickm: my2c says it's important for July not April. 15:23:47 isabela: ah right. i asked a few community people, they seemed to like the idea. unsure how useful will be in practice. 15:24:05 - is the stats tech report published 15:24:11 isabela: no harm in trying one or two such meetings. maybe it will develop into something nice. 15:24:15 nickm: agreed with paul. having results would be useful, but i think it is unwise to aim to have results. and just writing the code would let us say the one sentence "we're in progress of", which we can nearly say anyway. 15:24:34 asn: lets see how that go and maybe we can merge both meetings in the future 15:24:34 ohmygodel: i like all of these 15:24:47 syverson, armadev: what should we have done in July? 15:24:53 - i also have some ideas on short-term statistics that we could do, till we figure out the top-down stuff 15:25:06 I think we've been letting fear of Chris drive urgency to do all of a 3 year project in 6 months or OK maybe a year. 15:26:04 So let's talk a bit about anonstats. Since nickm brought it up and it's the current topic. 15:26:05 yawning: we are indeed trying to make sure R is about all hidden service stuff, not just the stuff on the immediate roadmap. 15:26:18 ok asn 15:26:18 armadev: ah ok 15:26:37 I updated #6411 with the next steps (beyond " I still need to write the docs for it") 15:26:50 it seems like simple additive anonymous reporting (with sigs to authenticate that you are a relay/hsdir) is a good first step 15:27:02 I think before coding AnonStats we should have a list of statistics that AnonStats would enable. I'm afraid that we are going to build the system and then figure out that we don't have much use for it. Or maybe we will think of a better system till we find a use for it. 15:27:03 this is anonstats1 15:27:05 if people care about the command naming, speak up, otherwise "ADD_ONION"/"DEL_ONION" will be the new names after I poke at it 15:27:20 Yawning: ok by me 15:27:32 and once that's done and the control spec diff is done, I will seek review for the branch 15:27:32 Yawning: I like. 15:27:55 asn: that list is easy 15:28:06 so, anonstats1 is easy. subsequent ones are harder, a bit 15:28:07 it is all statistics in our report that would be collected by HSDirs 15:28:12 I'll prolly squash it down too, since it has a lot of WIP ish commits and the actual changes aren't that large 15:28:26 because each HSDir is the same, there is no anonymity leak in the numbers themselves 15:28:37 can somebody provide a url to "anonstats1"? 15:28:39 it could also help beyond sponsor R, and let us eventually compute network-wide totals while removing stuff from extrainfos 15:28:58 ohmygodel: makes sense 15:29:08 ohmygodel: i guess next question is "which questions it helps us answer" 15:29:09 https://lists.torproject.org/pipermail/tor-dev/2015-January/008086.html 15:29:18 AnonStats1 ^ 15:29:25 i agree with asn that doing some more thinking about exactly what research questions we want to answer is a good idea. but i think everybody here agrees with that. 15:29:46 the main question it helps answer is 15:30:52 “what is the distribution of client activity over onion services" 15:31:11 why do we care about that? 15:31:29 i do not know 15:31:32 one reason is, it helps us properly explain onion services to the world 15:31:50 define "distribution" in the case? 15:31:54 if there are lots and lots of onion services being used 15:32:03 is that the same as "total number of descriptor fetches"? 15:32:06 then its definitely not all silkroad v. N 15:32:12 asn: yes 15:32:16 ok 15:32:42 total number of descriptor fetches per hidden service? or a sorted list of total number of descriptor fetches without specifying service names? 15:32:47 it's a bit like the gareth owen stat, but without mapping it to specific hidden services. 15:32:55 great, that sounds better. 15:33:03 its actually the number of descriptor fetches per HSDir 15:33:18 somewhere between "number of hidden service clients" and "number of hidden service accesses". 15:33:18 we could break it down further if desired 15:33:31 we cant aggregate it any more without a more sophisticated protocol though 15:33:51 i can be persuaded that this is a useful stat. or maybe an interesting one. 15:33:54 i2p has no such stats and they seem to manage fine 15:34:08 (and the HSDir is anonymous, as provided by AnonStats1) 15:34:25 are there other useful data that we could get from AnonStats1, that we can't get now? 15:34:31 qwerty1: ack 15:34:36 qwerty1: no they don't, actually. i2p has approximately zero users. 15:34:36 asn: yes, there are 15:34:39 qwerty1: we talked a lot abou tthis during the valencia meeting 15:35:04 the intro point statistics in our tech report could potentially be collected 15:35:08 qwerty1: we have decided to examine stats more carefully 15:35:29 qwerty1: and only do stats that can actually improve the tor network. and try to avoid stats that we are just curious about. 15:35:42 however, because the IPs are selected based on consensus weight 15:36:09 the magnitude of the number alone could reveal its identity, thus linking its stats to the onion service it serves 15:36:48 thus, we probably should modify AnonStats1 (e.g. by chopping up numbers into fixed-size blocks and submitting separately) if we want to it for IP stats 15:36:58 *to use it for 15:37:00 but what interesting stuff could IP stats tell us? 15:37:04 more than the HSDir stats that is. 15:37:20 it could tell us "how many clients got past the HSDir phase" 15:37:32 This is a reinforcing cycle. If we try to protect popularity of onion services (I continue to differ with asn and others about how important that is), then this should not reveal identity. 15:37:50 syverson: do you differ by thinking it is important? or unimportant? 15:38:18 I differ in thinking about how dangerous it is, and I think it could help us understand load etc. 15:38:29 syverson: i wish i had gotten you to sign a statement at the jan QRP when you and arma and i agreed that it is important to keep this private 15:38:49 :_) 15:38:57 :^0 15:39:17 using nickm's "If I could make a patch that plugs this leak, would I do it?" heuristic, I would definitely plug popularity leaks. 15:39:22 I wish I had gotten you to sign a statement that it isn't important to keep this private... Now that that's out of the way. 15:40:00 may I post a few questions that I would like to see answered using top-down approach? 15:40:12 asn: go 15:40:13 asn: IP statistics could be helpful in several larger research goals 15:40:36 including detecting botnets, communicating the value of onion services better, and improving performance 15:40:53 I would like to learn whether our magic numbers are good: I would like to know if 6 HSDirs is the best HSDir number. if 3 IPs is the best IP number. If it's reasonable to cycle IPs after 16384 introductions (INTRO_POINT_LIFETIME_INTRODUCTIONS). 15:41:03 toralf: 'git commit 529f12368057 in stem breaks "make test-stem" in tor' => thanks, looks like someone provided a patch for it on https://trac.torproject.org/projects/tor/ticket/15004#comment:16 15:41:09 btw, good morning world 15:41:19 o/ atagar 15:41:32 I would like to know whether we should specialize load balance HS circuits, since now they are load balanced like normal Tor circuits. 15:41:36 asn: add "if we need to cache hsdescs all day or just for an hour or something" to the list 15:41:49 yes 15:42:11 I'm curious to see whether we can learn how much unused bandwidth each relay has. To see if middle relays are indeed underused. 15:42:12 hm 15:42:26 I also think that if we think more about high latency hidden services, we will think of some statistics that could help us here. 15:42:40 isn't the bandwidth question really hard? 15:42:42 >.> 15:42:42 to see whether blending high with low latency is useful for us. 15:42:50 Yawning: yeah, I don't know if it's technically possible. 15:42:50 what are high latency hidden services? 15:43:10 armadev: unclear. people want to have high latency anonymous publishing. 15:43:28 it's worth investigating whether it can be done in Tor. 15:43:33 yawning: step one, become aware of the research questions that would be great to have answers for. a later step is assessing feasibility. even if they're unfeasible now, we can still tell people how useful it'd be to have. maybe somebody else is smarter than we are. 15:43:53 it's a big research question, I guess. but I think that answering it well, will require extra data about hidden services usage. 15:43:53 asn: d'you think obfsproxy would be the right candidate for a DNS tunneling transport? 15:44:10 armadev: fair enough, I thought there was ongoing research attention to that (isn't it a subset of "rework our bwauth stuff")? 15:44:27 asn: current onion service usage? Cause that may not be very informative. 15:44:50 yeah I haven't thought about this problem enough to be able to form a productive sentence, I'm afraid :( 15:44:57 federico3: eeeehm maybe. 15:45:03 syverson: true. we're building for the future we want, not the present we have. 15:45:14 asn: the sentence is "we should do research" ;>) 15:45:23 dns that's actually dns is going to be kind of slow 15:45:31 Yawning: *very* slow 15:45:53 and I don't feel great about shitting up the caches of the public dns infrastructure with all the queries for that 15:45:57 though that may be minor 15:45:58 (but usually enough for fetching email, IRC, SSH) 15:46:02 these are the top-down questions I could think of so far. 15:46:15 Yawning: cache-shitting might be _great_ for bridge discovery though 15:46:31 sounds great asn 15:46:41 nickm: yeah, I think some folks ran attacks to see how many people used iodine a while back 15:46:53 several of those hadnt occurred to me! 15:46:54 well, ran the analysis 15:46:59 asn: all of these sound like great things to learn. i think they were also in my original list of research questions i wanted to explore. maybe i should go back and find that list. 15:47:06 +1 on that list 15:47:14 +1 15:47:18 before moving onto writing the top-down list 15:47:23 can we close anonstats ? 15:47:31 yes 15:47:44 i want to say that 15:47:53 i agree that it need not be done by april 15:47:58 however 15:48:30 i would like to have a plan to have it done by june 15:48:37 assuming that we agree that it is worth it 15:48:48 ohmygodel: anonstats1 no? 15:48:50 yes 15:48:54 I think in that case we should try to have a spec by end-of-march, and probably an implementation of all the crypto too. 15:49:40 https://lists.torproject.org/pipermail/tor-dev/2014-October/007642.html and https://lists.torproject.org/pipermail/tor-dev/2014-October/007652.html 15:49:52 so are we agreeing to move forward on this ? do we need a vote ;-) 15:50:06 I vote we don't need one. 15:50:18 i delegate my vote to asn. i haven't been following closely enough to know what i should think. 15:51:00 I think the people to vote/decide are ohmygodel, asn, dgoulet, and nickm. 15:51:09 sounds good to me. 15:51:13 i think I will go with abstention for now. 15:51:24 I will be able to vote more usefully after we have some more data on the top-down list. 15:51:24 Hm. Part of me always wants to implement code. Part always wants to implement _other_ code. 15:52:15 tbh migrating many of our current statistics to such a system seems like a win to me in general, even if it's not that useful for future stats. 15:52:33 Maybe since asn wants to abstain, we defer a week until the top-down list is fleshed out? 15:52:35 asn: if you want to postpone this decision until after we have a top-down plan, i am fine with that 15:52:44 I think I can hold off till next tuesday on the spec/design, and spend the intermediate time doing a blind signature ed25519 thing, if somebody writes up the formulae 15:53:01 I would much prefer having the top-down list before deciding on anonstats1 proposal/implemenation, my 2 cents 15:53:18 (I see http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html , but that isn't quite Ed25519, since Ed25519 isn't quite Schnorr) 15:53:27 nickm: sounds fun. can you explain a little more what you need from the formulae. maybe email? 15:53:41 nickm: i think nick hopper was the one who told you it was easy? you might ask him 15:53:44 ok 15:54:07 asn: did we just implicitly decide that by next week you'd have the top-down research questions list more fleshed out? 15:54:22 nickm: actually let me see if i can provide the description at the level this blog post gives for other schemes 15:54:28 then you can say if thats enough 15:54:38 err, i could use even more, will send an email within 30 min 15:54:42 ok 15:55:03 so maybe we should instead talk about the top-down plan 15:55:06 armadev: seems so. 15:55:13 armadev: let's see how this goes. 15:55:42 fine with moving to top-down plan 15:55:56 fwiw, I also had a small list of statistics that we could do in the meanwhile 15:56:00 till we formulate the whole top-down thing 15:56:13 for example, I think statistics on HSDir attacks could be done now, without any extra little-t-tor code. 15:56:26 like identity keys per IP 15:56:36 and density of HSDirs in the hash ring 15:56:58 the "popularity of hidden services" paper has 5-6 heureistics that could be used to detect such attacks 15:57:03 asn: maybe we could do that in the hs health tool ? 15:57:19 i believe it's great to have this information on metrics.torproject.org so that they can be audited 15:57:23 asn: because all this computation from (past/now) consensuses will be needed anyway 15:57:35 yeah maybe 15:57:35 asn: and the goal is to publish it on metrics also 15:57:51 i recently learned that the hs health tool will eventaully be used on the real network 15:57:57 yes 15:58:13 so I'm not very familiar with how that would actually work, or when would that happen. 15:58:16 dgoulet: we should talk about data formats, collecting data, etc. at some point. 15:58:34 asn: how about we schedule a discussion about it? :) 15:58:40 dgoulet: ack 15:58:41 karsten: indeed, soon will request your help 15:58:48 ok 15:59:00 so you guys want to talk about top-down plan? 15:59:04 you have any ideas? 15:59:20 asn: i think the hs health tool will be really useful in answering some of your top-down questions, like "whether 6 hsdirs is the right number" 15:59:26 i think we should discuss this at a meta-level 15:59:34 isabela: btw, if you are interested in anything we are saying and you can't understand what we are saying, feel free to ask. 15:59:37 like, where and when and how will we write this 15:59:42 isabela: since our jargon use is quite extensive here. 15:59:57 armadev: ack 16:00:19 ohmygodel: "where": maybe it can be a different section of the stats tech report? 16:00:36 ohmygodel: "when": between now and july? maybe closer to now than july. 16:00:48 asn: that report should be frozen. i have pub release for it in its current form only 16:00:58 hah 16:01:17 different tech report I guess then 16:01:33 asn: hah indeed. imagine the press review of your hs blog post times 10. thats pub release 16:01:37 I'd want to make that tech report better before publishing though. 16:01:51 ohmygodel: sent 16:01:56 karsten: can we discuss that after this 16:01:58 nickm: ack 16:02:01 ohmygodel: yup. 16:02:28 so I guess we can make a shorter new tech report about the top-down thing 16:02:36 asn: “when” should be quite fast IMO. before april certainly 16:02:53 this isnt hard. i can write up my ideas right now in about an hour 16:03:27 also, we dont necessarily need to publish this as a tech report, because we’re not trying to answer all the technical questions 16:03:56 an etherpad transitioned to the sponsor r wiki makes sense to me 16:04:02 ohmygodel: true. but, it'd be great to list the questions, and then talk a bit about what we'd do depending on the answers we learn. 16:04:07 like, why is this an important question 16:04:30 and how will answering it help us take some useful action 16:04:40 armadev: true, but how does the tech report per se help w/ that? 16:04:56 i'm just saying if we do this thoroughly we'll have some pages of text 16:05:00 asn: tx - tx to valencia discussions I am getting it but will review the meeting log latter to make sure I didn't missed any 'next steps' thing 16:05:14 armadev: i agree 16:05:18 ohmygodel: i was hoping that the statistics from the HS health measurement that I mentioned above, could quench the sponsor's thirst for statistics. 16:05:25 d'accord. 16:05:36 so that we have proper time to think of more statistics in the future. maybe even till july if it's necessary. 16:06:11 i mean did the sponsor ever say that they only care about statistics if it's collected by relays and requires a little-t-tor code change? 16:06:28 asn: yes i agree that we dont need to have answered these questions with hard numbers 16:06:28 the sponsor doesn't even have a thirst for statistics. this is part of what we talked about in valencia. we want to understand hidden services and make them better. i, and several of us, figure that understanding them is a good first step. 16:06:56 however, we cant postpone all progress until we have fully discussed every research question, its implications, and how exactly we would solve it 16:07:29 [Are all HS ideas on-topic here? If so, does anybody have a feel for whether we should investigate PIR for HSDir retrieval?] 16:07:29 sure 16:07:50 How did we move from having a basic top-down list by next week to having a tech report for July? 16:08:08 syverson: im also wondering this 16:08:10 ok maybe we should see what we can do with this top-down thing till next week 16:08:16 and see how much there is to think in that space 16:08:21 maybe we are done in a week. 16:08:47 We don't have to be done, just done enough to answer the deferred question on anonstats1. 16:08:55 ok 16:09:13 syverson: agreed 16:09:39 The top-down thing can be a work in progress, that could indeed be firmer in the coming months. 16:10:19 ok 16:10:20 then 16:10:30 is the top-down list of questions in a ticket? (if not, should it be?) 16:10:45 it is not. 16:10:47 maybe it should be. 16:10:57 so this is the question of where 16:11:12 We can start a tor-dev thread about it. Or make a ticket. 16:11:15 may i humbly suggest etherpad->wiki again 16:11:20 I like the suggestion of an etherpad. 16:11:21 ok 16:11:25 that has worked well for us in the past 16:11:26 etherpad is fine with me. 16:11:43 or wiki as ohmygodel says or similar. 16:12:05 https://etherpad.mozilla.org/psNv5z99Z5 16:12:17 thank you asn 16:12:22 cool 16:12:32 ok 16:12:37 C'est tout for this week? 16:12:42 ehm 16:12:57 wow we are running long 16:13:01 yeah 16:13:07 ok so done with this top-down thing 16:13:12 and done with the anonstats topic too 16:13:13 no we're only 13 minutes in ;>) 16:13:17 haha 16:13:25 what else should we talk about? 16:13:26 i did have one small thing to discuss about publishing the tech report 16:13:31 i am a big fan of this direction -- i made a pile of tickets in september, like #13207 #13208 #13239 and others, and there's a lot more where those came from. 16:13:44 karsten had some thoughts about this 16:14:13 ok 16:14:14 well, I'd just want us to spend some time on finishing the report, rather than publish as-is. 16:14:22 ack 16:14:23 toralf: Thanks! Fixed: https://gitweb.torproject.org/stem.git/commit/?id=378bfaf 16:14:28 karsten: what is there to finish ? 16:14:31 asn: my only other emphasis would be on thinking about ways to answer the questions over time, rather than putting a lot of work in, and getting one number, and then needing to put all the work in again to get a new number later. 16:14:53 armadev: that all sounds like hs health tool job 16:15:03 how about we schedule a discussion (or start one on tor-dev) ? 16:15:04 ohmygodel: section 4 (?) is still a bunch of ideas thrown together, without much structure. 16:15:09 dgoulet: well, seems like we found a way to bridge the performance work with the statistics work? :) 16:15:18 asn: indeed 16:15:37 asn: much to do in the hs health so if you want to help me on that, be my guess! :) 16:15:45 For ohmygodel anything beyond cleaning things up, i.e., anything substantially new will require a new pub release. 16:15:47 dgoulet: well, sort of. are fast hidden services always out of preemptive circuits, so they always take longer to respond than they should? hs health tool can only go so far. 16:15:48 dgoulet: ack 16:15:49 I'm alsmot done with the little-t tor code for this 16:16:13 syverson: I think it's mostly cleaning up. 16:16:23 armadev: yeah 16:16:25 karsten: sounds good. 16:16:26 asn: is that research question i just raised in-scope for your idea of top-down questions? 16:16:26 it's been a while since I looked. 16:16:36 karsten: i think your section 4 sadness is a general product of our previous bottom-up approach. 16:16:55 asn: hmm, maybe. 16:17:01 at least i know that this is why i didn't like the tech report all this time. 16:17:02 No!!! Something else to defer until the top chimes in. 16:17:14 well, we could also write a better report based on this one, get it approved, and publish. 16:17:41 armadev: sure why not 16:17:50 armadev: noted it to the pad 16:17:58 That's OK too, as long as we know which we're doing. 16:18:18 karsten: i have to say that am opposed to spending any more time on this 16:18:27 i think the structure is perfectly clear and logical 16:18:41 i think the information is useful to people trying to understand how we reason about which stats to release and how 16:18:52 i think the value of adding to this document is low 16:19:05 so, it's not the quality I aim for. I could imagine that you publish without me. 16:19:07 and so if we cant agree to publish it nearly as-is, then we should let it die 16:19:43 yeah I also don't find that tech report particularly enlighting. I'm fine with publishing if other people want to though. 16:19:53 karsten: perhaps you could provide more detail. maybe you arent asking for that much 16:19:56 ohmygodel: are you stating your opinion or speculating about karsten's? 16:20:15 syverson: that was my opinion 16:20:34 I can provide more detail if I go re-read what we have. 16:20:36 i'm also fine with letting it die, but I think some of its sections are pretty good and could be copied to future tech report. 16:21:01 letting it die and reusing parts is also an option. 16:21:09 url to this tech report? 16:21:18 i'm mainly bothered by the "benefits"/"risk" approach which is not very fruitful IMO. 16:21:26 Hmm, can we defer this till Karsten re-reads and forms a strong opinion rather than speculating? 16:21:43 armadev: https://people.torproject.org/~karsten/volatile/hidden-service-stats-2015-01-10.pdf 16:21:44 btw, we're not very good at finishing things. we still have to resolve #13192 and #15013. leaving things unresolved makes me sad. 16:22:09 syverson: I can provide more details at next week's meeting. 16:22:20 karsten: #13192 has the necessary patch, just needs review 16:22:35 #13192 has been in my TODO list for a while. it's not an easy patch to review. 16:22:58 karsten: i would very much like to resolve this tech report. in fact, i thought we had resolved this tech report like a month ago. i would be read your thoughts about making it publishable by next week. 16:22:59 a Yawning would be very helpful since he basically told me how to fix it 16:23:05 Yawning: ^ #13192 16:23:13 Let's try to finalize finalize what's happening with this then. I think that will already be pushing ohmygodel's patience near breaking (if that's not too presumptuous to say). 16:23:19 *i would be happy to read your 16:23:32 hey, speaking of undone things. asn tells me we are losing relays that report the january statistics, since it's off by default and nobody knows we want it. we spoke of turning it on by default. we also spoke of me doing a public push among big relay operators to get them to switch it on. 16:23:43 meep? 16:24:00 is that the float thing? 16:24:04 Yawning: ye 16:24:05 ohmygodel: let's put this on next week's agenda. 16:24:16 not many thoughts to read right now. 16:24:21 karsten: ack. thanks! 16:24:51 syverson: you know me too well :-) 16:24:53 I'll look over the branch and sign off on it once I'm done eating 16:24:54 armadev: agreed about losing relays reporting stats. 16:24:56 :P 16:25:04 armadev: I think it was one of my post-it to come up with a patch that adds the necessary options to torrc file and then put it in need_review and then somehow magically decide if we want it or not by default in the meantime :) 16:25:31 Yawning: ack, thx 16:25:34 Anything else for this week? Gotta run soon. 16:26:02 unclear whether we should turn it on by default. i was almost persuaded and then nick said he doesn't like the idea. 16:26:34 to make this more complex, i would be more OK with turning it on by default if we had a stats aggregation system. 16:26:59 hot 16:27:41 even though I don't see of any powerful attacks that could happen with this stat enabled by deafualt. 16:28:03 what could be additionally revealed that isnt already revealed by the volunteers ? 16:28:25 nothing i can think of 16:28:36 it seems to me that if we’re OK having 5% of the network collecting it, we should be OK with 100% of the network doing so 16:28:40 i think the biggest issues we need to think of is when these stats get reported by tiny relays, like karsten said 16:29:01 5% 100% what's the difference? ;>) 16:29:05 havent we thought about this ? 16:29:12 yeah we have 16:29:26 at least I have. 16:29:32 ok yes we have 16:29:34 not exactly sure what you refer to, asn. 16:29:36 4.2.3 in the tech report 16:29:55 Was it simply new to nickm or were there specific questions? 16:29:57 I'm generally unhappy with security reasoning of the form "I cannot think of why X is worse than Y, therefore X is no worse than Y." 16:30:10 Compare with 16:30:13 karsten: that when tiny relays report these stats, they actually represent very few clients underneath. which might make us learn information about specific clients. 16:30:52 nickm: the analysis that went into deciding how to obfuscate the statistics was done under the assumption that all relays would be reporting it 16:30:53 "The threat model does not include an adversary who can do X, therefore we can weaken the system as much as we like against said adversary without actually making it weaker" 16:30:54 hmm ok. not sure when I raised that concern. and we also have laplace noise for that. 16:31:12 OK that's the offhand statements here, but there was analysis in the report 16:31:15 I'm more okay with "all relays report" if it includes something like the anonstats ideas 16:31:29 nickm: do you have a specific privacy concern ? 16:33:37 ohmygodel: not yet, but I think that stats are guilty until proven innocent 16:33:40 also, nickm just supplied a nice reason to do anonstats: enable automatic global collection of the # and BW HS stats that we are currently relying on volunteers for 16:33:45 nickm: acknowledged 16:34:01 yes, this discussion seems like a + vote for anonstats. 16:34:18 in fact, that reason seems enough to me to just decide now to move forward on anonstats 16:34:41 dgoulet: maybe add some unit tests to the routine? 16:34:54 so I think we should wrap this meeting up. 16:35:06 apart from that it looks good to me 16:35:10 if using it will in fact achieve consensus on collecting those two stats (# descs and # HS relay data cells) 16:35:26 Yawning: there are bunch of unit test for laplace testing which uses that but indeed more unit test for the specific function would be nice 16:35:29 ok, well, we can discuss that at the next meeting then 16:35:39 asn: i agree that we should wrap up and thanks for watching to time 16:35:40 yah, there's not a lot of cases to cover 16:35:51 Hrmm, ohmygodel let asn have the top-down overview by next week before pushing further IMO. 16:36:07 OK, I think us Tor folks should figure out what we we will be doing till next week. 16:36:31 I suggest test cases added, then come back to me for signoff 16:36:41 but up to you 16:37:10 * karsten re-reads stats report and thinks about publish or not; and revises metrics code based on asn's/dgoulet's review. 16:37:15 OK, it seems like I will be taking care of this top-down list situation till next week. 16:38:09 I would also like to take a look at the HS health measurement thing. 16:38:16 since it seems like the avenue to more statistics. 16:38:23 asn: oh yeah :) 16:38:26 or whatever we call these things 16:38:37 and I also need to write hte monthly report 16:38:55 and I also need to review #13192, but I'm not sure if I will be able to get to this responsibly. 16:39:00 why tor destroyed vidalia? there is no project page no more 16:39:05 asn: ill add to the top-down plan 16:39:12 jueok: #tor will be better for you 16:39:38 as to the other stuff in that branch I have no idea what the code does or is supposed to do ;_; 16:40:05 karsten: I will also look into #15013. 16:40:19 asn: thanks! 16:40:30 dgoulet: where are we on getting the controller events that dump the hs desc? once we have those in some tor, we should get the sri people to upgrade their tor so they're recording those. 16:41:29 armadev: I have all the patches needed for the "dump content" (spec and code) 16:41:58 armadev: currently working on debolting the hs fetch desc. code 16:42:16 ok adios amigos 16:42:25 ok thanks guys 16:42:30 let's end this mega meeting omg 16:42:32 #endmeeting