16:00:47 #startmeeting SponsorR 16:00:47 Meeting started Tue Feb 10 16:00:47 2015 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:54 hello friends 16:01:08 let's get going with the usual drill 16:01:14 let me start with a status report, and you go on with yours 16:01:29 over the past week, I worked on the blog post about the HS statistics 16:01:42 karen is looking at it today, so it should be ready to post RSN 16:01:53 i also did various SponsorR bureaucracy 16:02:10 and I started a [tor-dev] thread about more statistics that we could collect 16:02:22 i skimmed over aaron's reply and it had some smarte comments. 16:02:25 *Smart 16:02:32 and that's that I think from the SponsorR world. 16:02:36 who next? 16:02:39 ok i can go 16:02:42 ohmygodel: please 16:02:51 i helped work out the number for the HS stast blog post 16:03:10 i made a wiki page summarizing the terminology discussion (linked to from the sponsor r wiki page) 16:03:15 thats it 16:03:31 thanks that's useful 16:03:34 * karsten can go next 16:03:35 karsten: please 16:03:50 I looked at ohmygodel's math to calculate fraction of hidden-service traffic, 16:04:05 and found a factor-two error introduced in the extrapolation report. 16:04:34 I posted the calculation to tor-dev@. that's ohmygodel's, asn's, and my joint work. 16:04:55 I also pushed sources for report graphs and report sources to git. 16:05:09 and updated the published report to take out that factor-two bug. 16:05:12 that's all. 16:05:20 that's good. thanks! 16:05:26 yeah good we found that factor-two bug. 16:05:31 yes! 16:05:46 is the tech report updated ? 16:05:47 dgoulet: syverson ? 16:05:49 it is. 16:05:50 https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf 16:05:57 * dgoulet can go 16:06:10 ohmygodel: see the footnote on page 3. 16:06:19 ok cool, the 1/31 date threw me off 16:06:50 dgoulet: go! 16:07:36 I'm no more sick and 0.2.6 is almost out so now more time on sponsorR, mostly right now working on hs health measurer (#13209) 16:08:04 last week was ETOOMANY little-t tor so this week I want to focus solely on SponsorR 16:08:05 * dgoulet done 16:08:14 * syverson next 16:08:20 syverson: yes 16:08:36 I resolved terminology discussions with ohmygodel. 16:08:59 Began diving into problems with Eigenspeed for BW stats. 16:09:04 * syverson done 16:09:11 thanks 16:09:16 OK, that's good. 16:09:20 Quite fast. 16:09:27 Should we move to discussion phase? 16:09:30 What do we want to discuss? 16:09:57 terminology thoughts ? 16:10:07 Sure. 16:10:17 Maybe we could also discuss the next stats? 16:10:22 and of course what we will bve doing next week... 16:10:23 ok 16:10:28 anything else? 16:10:59 sounds good to me. 16:11:00 ok 16:11:04 let's go with terminology thoughts. 16:11:10 so as i said in my email 16:11:11 unfortunately, i haven't had time to read the thread or wiki entry. 16:11:14 how can I help here? 16:11:20 im going to start preferring the term “onion service” to “hidden service” 16:11:42 you can help by considering if “onion service” is right for you :-) 16:11:50 i think onion service is right for me. 16:11:55 also i want some opinions about broadening the discussion 16:11:58 i'm not sure if we should start switching now. 16:12:10 like, i don't think we should say "onion service" on this blog post. 16:12:23 I already have been using this terminology in papers and discussions, e.g., with DARPA and DoJ. 16:12:30 mainly because "hidden service" is super established brand name, and switching from it will require some marketing skills. 16:12:57 It's branded with a coward's shame. 16:12:58 i think you could make the change with a footnote explaining that “onion service” = “hidden service” and why you prefer that term 16:13:01 i've been using "onion space" instead of "darknet", because darknet is terrible and I don't think it's official terminology (unliuke hidden service) 16:13:09 Sorry, cultural reference that dates me. 16:13:24 yeah syverson *whoosh* 16:13:39 hm, asn, that is not how i had understood “onion space” 16:13:42 but actually i like it better 16:13:49 i had understood it to be the set of onion addresses 16:14:02 but maybe it it better used as the set of onion services 16:14:09 what is the set of onion services in your lingo? 16:14:10 i like it 16:14:15 nothing haha 16:14:19 im changing the wiki ! 16:14:22 there is no replacement for darknet? 16:14:35 no, there really should be one 16:14:37 i think that's the term we really need to replace. it's so shit. 16:14:42 totally agree 16:14:51 Not sure there should be one honestly. 16:15:11 many people seem to want a word for this cloud. 16:15:26 for this network of computers. 16:15:37 new def’n: '''onionspace''' should be used to refer to the set of onion services that have been available "recently" (context-dependent). 16:16:39 i don't think we should change the blog post fwiw. 16:16:40 fine if you dont want to change the blog post. it will be a gradual change in any case. 16:16:46 ok. 16:16:59 Perhaps we can split hairs: onionspace= space of onion services. .onion space= space of .onion names. 16:17:04 Is that too sublte? 16:17:16 subtle 16:17:17 i would prefer “onion address space” for the latter 16:17:48 obvious analog to, e.g., “IPv4 address space” 16:17:49 or onion domain space? 16:18:10 what about protocol details? hidden-service directory -> onion directory? hidden-service client -> onion client? hidden server -> onion server? 16:18:23 karsten: oh wow, you just opened the pandoras box. 16:18:29 Maybe you and I aren't actually done, ohmygodel. ;>) 16:18:41 change the consensus flags to OnionDir. 16:18:48 karsten: we havent discussed new terms for those 16:18:49 asn! 16:19:03 Ermm, I thought we had a bit. 16:19:12 i think theyre less necessary because fewer people need to refer to those things 16:19:27 at least HSDir 16:19:30 true. I'm just thinking how to write the next tech report. 16:19:31 ohmygodel: what's your replacement for "encrypted services", which is also terrible name but fortunately far from established right now. 16:19:40 hidden-service client -> onion service client seems fine 16:19:55 similarly, hidden server (new term to me actually) -> onion server seems to work 16:19:58 We've been quibbling over "encrypted service" 16:20:01 karsten: oh wow massive rebranding! :) 16:20:13 yeah this is serious rebranding stuff. 16:20:23 it depends whether these are aonother kind of onion service or a different animai. 16:20:26 sounds like 224 + rebranding would be perfect 16:20:31 I think Tor has a PR team these days. they should definitely be informed of this. 16:20:32 asn: given that the details of such services arent finished, the name doesn’t need to/can’t be made right now 16:20:38 I was pushing for "Tor-required service" 16:20:47 best suggestions are: “direct onion service” and “Tor-require service" 16:20:49 dgoulet: yes exactly. that's also what I think. Do official rebranding when the onion address changes to 56 characters. 16:20:52 What he said. 16:21:06 interesting names. 16:21:14 i don't realy *like* them though. 16:21:17 :P 16:21:30 more useful than "encrypted services" for sure though. 16:21:44 fair enough, im not in love either :-) 16:22:09 I think we need to change how we refer to things amongs ourselves and with the public sooner rather than later, but not needed for tor-required services before they're designed. 16:22:49 right 16:22:57 OK. I think we can move on to next subject? 16:22:58 Switching to "onion" for existing HS stuff should be doable and recommended now. 16:23:04 Yes please. 16:23:05 asn: one question 16:23:16 I think a [tor-talk] mail with our intentions and ideas might be a good step at this time. 16:23:19 advice for asking for more opnions ? 16:23:45 How about [tor-dev] rather than [tor-talk]? 16:23:48 sure 16:23:49 ok i dont subscribe to tor-talk. what is it used for? who listens to it? 16:23:54 ok tor-dev instead 16:24:04 more community (people who setup HSes), less developers. 16:24:08 but [tor-dev] is fine too. 16:24:21 can you send this mail ohmygodel ? 16:24:26 yes 16:24:29 ok that's great. 16:24:30 thanks! 16:24:51 next subject? or question left? 16:25:19 next subject 16:25:20 ok 16:25:27 Should we discuss more stats? 16:25:37 sure 16:25:46 not sure if that's the best use of our time though. 16:26:10 asn, what do you suggest? 16:26:21 not sure how to make this a worthwhile discussion. 16:26:29 we could walk over the 4 proposed stats and discuss them. 16:26:36 but it's going to take a while, and maybe mailing list is better. 16:26:44 what do you think? 16:26:50 do we have more discussion topics? 16:26:52 if not, we can do it. 16:26:54 yeah i think thats better over the mailing list 16:27:03 you mean you prefer mailing list? 16:27:12 i prefer the mailing list 16:27:13 i do wonder if someone could remind me what our plans are for stats this quarter 16:27:26 yes that's a good topic. 16:27:41 we are suppose to advance both the "more stats" thing, and the "stats aggregation" thing9~. 16:27:52 at this point, I think advancing the stats aggregation thing might be more worthwhile. 16:27:52 ohmygodel, asn, you mean the memex sri list or the hs-stats list? 16:28:20 because if we have the stats aggregation thing, we can do more stats, and we should also port the existing stats there too. 16:28:33 syveson: we have a thread on tor-dev 16:28:45 i meant the [tor-dev] thread that was tstarted yuesterday in this case. 16:29:03 OK sounds good. (Too many lists.) 16:29:12 asn: i agree 16:29:27 ohmygodel: ok. 16:29:30 i had thought that we could knock out some easy additional stats for a quick win 16:29:53 ohmygodel: agreed. 16:30:01 we should think about what's realistic to present in april. 16:30:19 and maybe we still can (the # of RPs established seems useful and easy) 16:30:21 if we only aim for better stats aggregation, maybe we'll have a design, but no results. 16:30:52 i can very easily see the "easy additional stats" draining all the remaining time though. 16:30:56 I'm saying that without really following what stats we might want to add. 16:31:02 that is proposal, implementation, testing, deployment, analysis. 16:31:07 asn: yeah.. 16:31:11 this is easy 2 months. 16:31:28 allowing enough time on the meanwhile for public review etc. 16:31:42 i'm not sure. the tradeoffs are interesting here. 16:31:48 we can focus on one thing this week and re-evaluate next week whether that'll work out until april. 16:32:14 is nickm interested in helping out with the stats aggregation thing? 16:32:29 asn: yes 16:32:35 ok. 16:32:50 i can read the AnonStats3 and other emails this week. 16:32:52 in particular, he was interested in helping implement the required crypto 16:33:03 he suggested that it might be a fun Rust project 16:33:13 hah oh wow 16:33:13 ok 16:33:37 (i sent him the abe and okamoto paper on partially-blind signatures) 16:33:49 i just remembered that AnonStats has crypto. 16:33:56 and a dedicated StatsAuth. 16:34:03 yup :-D 16:34:26 OK, I really don't think it can be finished by mid-April. 16:34:31 so we are looking at something like this: 16:34:49 - Either we get 1-2 extra stats for April but not much progress on the AnonStats front 16:35:04 - Or we do some progress (proposal, start of implementation) on the AnonStats front, but no extra stats 16:35:38 I think that the latter is more worthwhile. 16:35:41 ohmygodel: hmmm, japanese cryptographers, a bit of an oddity 16:35:42 :P 16:35:48 not at all! 16:35:58 (lemmie guess, they're with NTT or something) 16:36:21 there are some great japanese cryptographers 16:36:22 However, I don't want to start implementing AnonStats so soon. 16:36:27 haha yeah NTT 16:36:32 Which pushes me towards the former... 16:36:32 hah, knew it 16:36:41 the NTT folks did elligator^2 which was spiffy 16:36:48 their english-as-a-second-language makes their papers often a challenge to read, though… 16:36:58 not for me 16:37:09 dictatorship! 16:37:14 Since both projecst are currently in the discussion stage though. 16:37:22 Maybe we can advance the discussion during the upcoming week? 16:37:26 And see where it takes us next week? 16:37:27 (I just immediatly think of stuff like MISTY/Camellia when it's japanese crypto) 16:37:32 I will focus on the ANonStats discussion personally. 16:37:43 freemode for CGI! 16:37:46 I should re-read that thread, too. 16:37:47 well did secure bw measurement is needed for AnonStats anyway? 16:38:04 oh 16:38:11 dgoulet: no 16:38:26 dgoulet: not a good time atm 16:38:27 How about the people who invented re-encryption mixes, Yawning? There is lots of Japanese crypto. 16:38:41 Sebastian: no worries 16:38:44 dgoulet: what's up? I'll answer asap 16:38:57 syverson: yeah, guess I just need to read more papers 16:38:59 i mean, the bandwidth-weighted stats vote will be more secure if you can trust the bandwidth weights, but it will be no less secure than tor itself... 16:39:37 why you need gun? 16:40:12 OK. As you can see, it's not clear to me what we should do here. 16:40:31 asn: i think exploring anon stats collection to see how that might work is a fine idea 16:40:32 Maybe I can read AnonStats3, and see if it's something that can be written into an official proposal. 16:40:35 also remember that we want to do other stats-related things this quarter. 16:40:44 finish that other tech report, implement stats on Metrics, etc. 16:40:54 karsten: can you handle the metrics side? 16:41:07 i'm not that concerned with the other tech report being finished. 16:41:07 asn: yes. but then I cannot handle other things. 16:41:13 karsten: what other things would you handle this week? 16:41:32 asn: nothing yet. whatever is most urgent/important. 16:41:46 OK. Maybe you can take the metrics incorporation. 16:41:57 sure. 16:41:58 I can take the AnonStats thing, and maybe talk some more about extra stats. 16:42:25 sounds good. 16:42:29 And I'll try to have some sort of plan wrt stats results presentable by April by next week. 16:43:00 sounds plausible? 16:43:05 if we can decide on which stats to collect also, I can get started on the code/proposal if you need to be offloaded 16:43:33 well, if we decide that AnonStats is doable soon-ish, maybe we shouldn't implement the other stats just yet and just do them in AnonStats when it's ready. 16:43:56 probably better 16:44:14 any dictators online in here? 16:44:15 will there be a proposal for anonstats? 16:44:17 like *maybe* we can have some AnonStats stats by the *next* quarterly meeting on July. 16:44:20 karsten: yes. 16:44:34 asn: great. 16:44:35 it's something that relays will need to start doing, so it really needs proposal. 16:44:51 it's going to be quite a big project. and I don't really volunteer to implement it. 16:44:57 heh 16:45:06 and maintain, of course. 16:45:09 ... 16:45:15 but the ground work needs to happen anyway. 16:45:42 yeah it would be great to make it as modular as possible 16:45:42 yes. just saying that a quick-and-dirty implementation is not what we want. 16:45:42 so OK... 16:45:56 karsten: yeah 16:46:07 karsten: some sort of prototype might be useful. 16:46:12 oh sure. 16:46:19 but what the Tor relays actually use needs to be *proper*. 16:46:38 OK. Next topic? 16:46:52 I think we are done with topics. 16:47:09 great 16:47:14 Do we have things to do next week? 16:47:21 I think I just solved this for me. 16:47:27 i do 16:47:30 Karsten, you do work on metrics integration? 16:47:31 * karsten starts adding graphs to Metrics. 16:47:33 dgoulet, you do? 16:48:00 HS health! + Testing 16:48:01 karsten: btw, I wanted to tell you, that even the smaller figures of the extrapolation tech report would be very interesteing in metrics 16:48:22 karsten: like, if metrics could display the probs of becoming an HSDir over time for all relays, like Figure 6 16:48:27 that would be very nice. since we could monitor it in real time 16:48:33 and spot any anomalies. 16:48:41 dgoulet: OK, I assume you know what you will be doing there. 16:48:42 yes that falls into hs health also quite well ^ :) 16:48:43 dgoulet: do you need help? 16:48:53 asn: yes I know, and yes I'll need help on some reviewing 16:49:08 ok 16:49:21 did we pick a time for next week? i should mention that the only sponsor r thing im planning to spend major time on for the next two weeks is peerflow, and so its not absolutely crucial that i am able to attend. 16:49:32 (and help on not falling too much into little-t tor fixes :P) 16:49:33 ohmygodel: ah good! 16:49:48 so we are talking about next week on wednesday? 16:49:55 but karsten wont attend? 16:50:06 ohmygodel: oh btw, I might have missed it but did you manage to convince chris that peerflow is the new black? :) 16:50:06 asn: will think about what graphs to add. 16:50:15 asn: I'll try to attent. 16:50:16 if ohmygodel is spending time on peerflow, maybe we can restore the meeting to the normal time, and have karsten but not ohmygodel? 16:50:19 * karsten gotta run; phone 16:50:33 ah karsten cannot do tuesdays either... 16:50:33 Have folks seen http://www.wired.com/2015/02/darpa-memex-dark-web/ 16:50:41 sjmurdoch: not yet. 16:51:06 sjmurdoch: oh wow just read the title.. 16:51:10 ok wed. 2/18 at 1600UTC 16:51:21 ohmygodel: seems so. 16:51:45 OK, so we are done here guys? 16:51:52 oh god. onionspace! 16:51:57 done asn 16:52:12 dgoulet: im interested in your health service 16:52:20 ohmygodel: sure 16:52:21 could you summarize it ? 16:52:39 ohmygodel: If you haven't seen, I've used some comments from you to inspire this: https://theconversation.com/tor-the-last-bastion-of-online-anonymity-but-is-it-still-secure-after-silk-road-35395?utm_medium=email&utm_campaign=The+Weekend+Conversation+-+2419&utm_content=The+Weekend+Conversation+-+2419+CID_f257b679c0ae38a0bf3823cee90d82f4&utm_source=campaign_monitor_uk&utm_term=Tor%20the%20last%20bastion%20of%20online%20anonymity%20b 16:52:40 A nicer URL: https://theconversation.com/tor-the-last-bastion-of-online-anonymity-but-is-it-still-secure-after-silk-road-35395 16:53:46 ohmygodel: last point at the bottom: https://lists.torproject.org/pipermail/tor-dev/2015-February/008230.html 16:54:17 ohmygodel: there are multiple things we can do with it, mostly right now i'm interested in knowing the impact of relay churn and reachability 16:54:24 #endmeeting