16:00:47 #startmeeting SponsorR 16:00:47 Meeting started Tue Feb 3 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:49 Hello friends, 16:00:54 let me start with a short status report. 16:01:03 during the past week, I did a few sponsorr stuff 16:01:13 I fixed the unittest that was failing on 32-bit machines. 16:01:24 (that took longer than I wanted) 16:01:30 I wrote a draft of the blog post about the stats results. 16:01:33 (We need to discuss this later) 16:01:50 And I did some PM bureaucracy, which I still need to do some more of. 16:01:54 And that's that. 16:02:09 I haven't read some of the threads that were recently started and I need to look at (HS naming, HS stats enabled by default) 16:02:14 (but I also want to talk about that later). 16:02:18 Who next? 16:02:23 i can go 16:02:25 please 16:02:46 1. Edited etherpad of statistics to collect (https://etherpad.mozilla.org/817nh2h1-hstats) to give my opinion on each 16:03:09 2. Contributed to blog post discussion, especially working out the fraction of HS traffic number 16:03:27 3. invited aagbsn to work with us and come to this meeting 16:03:55 4. talked to nick about guard stuff, contributed to that tor proposal (241), and asked nickm about contributing to sponsor r 16:04:02 5. peerflow work 16:04:19 6. suggested we adopt new HS terminology 16:04:20 done 16:04:23 ack thx 16:04:26 next? 16:04:31 me? 16:04:33 please! 16:05:04 Not much. Talked to ohmygodel about terminology, peerflow issues, and stats. 16:05:32 Started interaction with DoJ, explaining to them how our stats can help them. 16:05:54 Some interactions w/ PM about bureaucracy and other things. 16:05:55 Done 16:05:57 (btw, dgoulet is a bit under the weather today, so he might or might not be around) 16:06:06 thx syverson 16:06:07 :( 16:06:08 karsten: ? 16:06:14 sure. 16:06:15 karsten: wanna go next? 16:06:16 thx 16:06:29 I spent most of the week on finalizing the extrapolating stats tech report. 16:06:32 https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf 16:06:37 karsten++ 16:06:48 including long and very helpful discussions with ohmygodel and asn. 16:07:11 I also started reading the other tech report, so that we can publish that one soon. 16:07:24 I like the content, but I'd like to spend more time on the presentation. 16:07:52 so, unless anyone else wants to work on that report, I'd want to take it for the week. 16:07:59 yes sure take it. 16:08:08 that's all. 16:08:17 i'd suggest putting special focus on the few statistics that ohmygodel wants to see 16:08:21 the ones here basically https://etherpad.mozilla.org/817nh2h1-hstats 16:08:30 oh they are more now. 16:08:33 yeah, I didn't know about that pad. will take a look. 16:08:47 I'd also be interested on a rationale for collecting those stats. 16:09:00 Basically the 'benefit' thing, but more refined. 16:09:01 asn: probably the "Benefits" part 16:09:05 yeah 16:09:10 Like, what kind of questions do we answer by doing those stats? 16:09:17 "How many HS clients are there?" 16:09:28 "How many HS clients are using outdated Tor?" 16:09:29 etc. 16:09:40 point of order: are we discussing now? 16:09:53 eeehhhhm 16:10:01 let's say yes. 16:10:04 since karsten is done. 16:10:05 great :-) 16:10:10 karsten: i did link the stats in the etherpad to the relevant section 16:10:32 and i added some stuff to the benefits/risk sections that would probably fit well in that report 16:10:33 are these additions? 16:10:48 like, should I merge pad parts into the report? 16:10:56 e.g. descripto fetch failures are useful for detecting botnet client trying to connect to a dead botnet c&c 16:11:04 karsten: yes, if you wish, that would be good 16:11:05 that's true. 16:11:10 ohmygodel: oka. 16:11:11 okay 16:11:18 are we OK with specifically targetting botnets with that stat? 16:11:22 but leave my opinion lines out (those starting with [ohmygodel] 16:11:25 ) 16:11:34 ok. 16:11:58 asn: yes, that was my argument to roger about how we could tackle that problem, and i think he was convinced 16:12:06 i'm just thinking 16:12:16 how neutral it is philosophically 16:12:21 to make a stat to target botnet usage. 16:12:33 i also don't like botnets, don't take me wrong. 16:12:42 it is useful more generally 16:12:51 that just happens to be a particular case of interest 16:12:53 but if we get in this line of thinking, maybe the next step is to make a stat that targets people that use HSes for X. 16:13:22 a bad X or a good one? 16:13:35 in fact, my argument about looking at this stat was exactly because it is a general statistic that can be collected safely in principle 16:13:44 asn: I get your point. 16:14:07 ohmygodel: yes, I also see it as a plausible statistic. 16:14:21 anyway, just something to think about maybe. 16:14:37 or maybe, I'm not sure if I want to know how many people use HSes with explicit authorization. 16:14:39 asn: We should distinguish topics, e.g., free speech, olive oil for sale, etc. from structurally different uses, e.g., botnet cnc, http, etc. 16:15:04 syverson: true 16:15:19 it's just not toooo far away from making a stat that counts people who visit HS that have child abuse material. 16:15:27 in the sense, that both activities are widely perceived as bad. 16:15:32 asn: do you wish to go through each of the stats in that pad individuall right now? that could take a while 16:15:39 you are right ohmygodel 16:15:40 i'm sorry. 16:15:47 it's just some thoughts I got while writing the blog post the other day. 16:15:50 ok sure 16:15:58 actually my recommendation is pretty simple 16:15:59 so yes, karsten, please take over that tech report for now! 16:16:03 hi 16:16:11 that are very few interesting statistics that don’t require some kind of anonymization 16:16:14 asn: I think we should focus on the structural/technical similarities and intentionally ignore the moral ones. 16:16:54 ohmygodel: right 16:16:55 what would be the theoretical minimum runtime requriements to run a tor relay? libc, tcp/ip stack, what else? 16:17:11 TLS 16:17:12 asn: is https://gitweb.torproject.org/user/karsten/tech-reports.git/log/?h=hidserv the latest source? 16:17:13 fastmonoid: sorry having a meeting in this channel right now, so there will be lots of noise. 16:17:13 I'm thinking about a purish tor DomU 16:17:23 karsten: let me look 16:17:28 libevent 16:17:29 karsten: i think so yues. 16:17:34 asn: okay. 16:17:47 so I have another topic I want to touch during the discussion session, 16:17:48 the low hanging fruti appears, to me, to be the following: (1) Number of descriptor updates (total count and distribution), (2) Number of RPs established on relays, (3) Number of circuits using TAP and nTor, and (4) Number of descriptors with encrypted introduction points 16:17:51 asn: ah ok thanks, i'll pipe down till its over, 16:18:08 ohmygodel: ack 16:18:42 quick question regarding (2) ? 16:18:47 sure 16:19:03 so, if a relay reports stats on # of rend cells and # of established rend points, 16:19:13 there's probably a correlation between the two. 16:19:16 you can get the average or sth 16:19:17 yes 16:19:27 now, our laplace noise, 16:19:47 it might be possible to guess how much noise we added by comparing the two stats. 16:20:04 which somewhat defeats the purpose of the noise. 16:20:27 asn and I discussed this some time ago, this is just the first example where it could be a problem. 16:20:43 i dont see the problem here 16:20:48 both are noisy 16:21:04 Different samples for the noise? 16:21:14 for those *specific stats*, their values are so diverse over time, that I'm not that afraid of this problem. 16:21:17 syverson: yes 16:21:23 v2 16:21:34 EWRONGCHANNEL 16:21:44 asn: yes, it's just an example, and maybe not a good one. 16:21:45 but it's definitely something that we should have in mind. 16:21:52 so, when we add the third related stat, 16:22:03 it will become even easier to guess what noise we added, etc. 16:22:09 right 16:22:20 something to keep in mind. no need to solve this today. 16:22:36 i agree. 16:22:37 agreed. the general problem is that a “single action” could affect multiple statistics 16:22:42 right. 16:23:02 the “solution” is that you add multiply the amount of noise by the number of statistics taht a single action could affect 16:23:15 if we migrate all these stats to our future "stats aggregation" scheme, maybe this problem becomes less important. 16:23:20 this is a good reason to keep the number of statistics lo actually 16:23:40 indeed, we can increase the noise. 16:23:46 asn: yes, if we can cut down the noise by not having to add it per relay, then this becomes a real solution instead of a killer of accuracy 16:24:33 karsten: thanks for bringing up this issue, it is actually really important and could affect our long-term roadmap 16:24:36 i was thinking the other day, that since we add noise 3000 times, and the noise is from a symmetric distribituion, in the end lots of the noise will cancel out. 16:25:02 and maybe it's even possible statistically to find out how much noise will cancel out probabilistically. 16:25:15 asn: the noise is added to completely separate sets of actions, so they dont cancel out 16:25:53 if you added noise 3000 times to the same statistic (or statistic representing shared underlying actions), then yes you would have this issue 16:26:17 *statistics representing shared… 16:26:36 hmm ok. will need to think more about this. 16:26:57 btw, does anyone have any discussion topics they really want to see discussed/ 16:27:00 so that we don't go blindly. 16:27:03 yes 16:27:06 shoot 16:27:08 1. What statistics to collect? Anonymous stats collection? 16:27:10 2. What to do with roadmap? 16:27:14 3. Blog post 16:27:19 4. HS terminology 16:27:22 ok good. 16:27:29 5. publishing other tech report (did we finish this?) 16:27:35 i also want to touch these topics. 16:27:58 btw, before touching these topics 16:27:59 let me tell you 16:28:03 re 5, how about I run with the report for the week and we discuss that more next week? 16:28:10 that with this SponsorR work, I end up sending more mails than coding lately. 16:28:23 and it so happens that all these mails I'm sending go to sekrit lists or sekrit threads. 16:28:30 and this really demotivates me from sending emails. 16:28:32 like for example today 16:28:39 I had to look at the extrapolating thread, which is sekrit thread. 16:28:44 the HS terminology thread, which is on memex. 16:28:50 karsten: sounds great. i agree that it needs some cleanup (i did some ad hoc in order to submit it for review), and fyi i got approval from chris white, and so i should get a publication release in 2-4 weeks 16:28:57 and the "enable HS stats" thread, which is on hidserv-stats. 16:29:16 and all of the feedback I would give is research. I don't really understand why we need to do research in sekrit channels. 16:29:32 and also, the two last threads I mentioned "HS terminology" and "enable HS stats" 16:29:37 are something that the communityu should give feedback on. 16:29:44 asn: i have no problem cc’ing any of the tor mailing lists on any of those discussions. i generally send emails to the people i think actually want to read them 16:29:55 so even if something is decided on those sekrit lists, the thread MUST also happen on tor-dev 16:30:04 so to me, it seems like a delay to do disucssion on sekrit lists. 16:30:19 +1 to move all this to tor-dev ML 16:30:22 and also it makes it harder for the community to be involved, because what we do is 16:30:27 * dgoulet lives 16:30:37 in the middle of the discussion, we start CCing [tor-dev] and no one has any idea what we are talking about. 16:30:56 asn: I talked to ohmygodel about having the terminology thread there. It's also a way to get initial gorund work done before moving to noisier channels. 16:31:12 i don't think there is lots of noise in [tor-dev]. 16:31:32 and also, I'm not sure what we gain by deciding something between me, you, aaron and rob. 16:31:58 anyway, something to think for the future again. 16:32:02 True. I was thinking that would be a fine place to move it. I think ohmygodel started on the memex list because there was related discussion there. 16:32:22 "True" was about not much noise on tor-dev. 16:32:38 anyway 16:32:42 let's go to the discussion tpics now. 16:32:52 well with respect to the terminology thread, i had a very specific goal of being consistent within this project, i am not ambitious enough to try and change all of tor’s mind 16:33:30 ok moving on 16:33:48 So what should we discuss. 16:34:04 Roadmap is here: https://etherpad.mozilla.org/LDiWZpI1sz-roadmap 16:34:09 i think it has sort of stabilized. 16:34:19 and I believe it's also prioritized by now. 16:34:40 It's obvious that we won't get everything done by April. But let's at least get the most important stuff done. 16:34:40 agreed, should it be merged to the wiki ? 16:34:47 yes. 16:34:55 we didn't do this on the previous SponsorR phase. 16:34:58 but we can do it on this one. 16:35:07 I can do this at some point before next week. 16:35:25 great ! 16:35:27 ok 16:35:36 that's one thing. 16:35:39 let's move to blog post. 16:35:46 we have a draft. 16:35:54 i think the main question is whether to include the "How much of Tor is HSes" 16:35:58 agreed 16:36:19 it seems important enough to wait for if necessary 16:36:24 however, i dont think we need to wait :-) 16:36:29 that's one way to see it, yes. 16:36:34 i also think it's very important. 16:36:40 (i mean, i dont see why we cant come up with numbers today) 16:36:57 Another main question is whether to say we have this report that talks about of lots of important things many would like to know for Tor vs. we got paid to do the following. 16:37:02 i'm afraid that the numbers we come up with are not going to be accurate. 16:37:13 asn: im not, and i dont understand why you are 16:37:15 can you explain ? 16:37:23 I don't have time to evaluate the math. 16:37:33 I hardly have had time to evaluate the math of the extrapolating thing over the past weeks. 16:37:42 ok can you trust me ? 16:37:47 i actually can. 16:37:52 i trust karsten did the extrapolation stuff correctly 16:38:08 i can rederive the traffic statistics from the extrainfo descriptors today 16:38:17 karsten did awesome work on the extrapolation stuff. 16:38:18 i just finished writing code to do that for peerflow 16:38:22 but he did a small mistake with the 2% figure. 16:38:28 and that mistake got publiced quite widely. 16:38:40 i think it actually worked out perfectly 16:38:49 That wasn't a mistake. It was a valid upper bound. 16:38:54 is that a mathematical coincidence? 16:38:59 syverson: hah sure 16:39:00 :>) 16:39:03 because he double counted the HS traffic but then didnt double the HS traffic because HS circuits are twice as long 16:39:06 so in the end, perfect :-D 16:39:39 should I prioritize this over the other tech report? 16:39:46 I'd really want to understand the math there. 16:39:47 karsten: i think so. if you want to. 16:39:55 karsten: i didn't understand if yuou want. 16:40:04 or you want to do this with peace and quiet over the next months. 16:40:12 i assumed the latter, that's why I've been pushing to not do this on this blog post. 16:40:17 karsten: i agree, especially because we have at least 2 weeks until i get a release on that tech report 16:40:30 but if you want to spend the next week thinking about this. we can publish early next week or something. 16:40:30 so, what about cell stats? 16:40:39 didn't we want to compare them to hidserv-stats? 16:40:49 I trust ohmygodel, but if people want to take another week so that all are comfortable what's the harm? Is it important to rush this out this week? 16:41:15 in a week sounds good to me. 16:41:18 syverson: i don't think I will be able to take a look until next week. and I just learned that karsten might be able to do so though. 16:41:29 OK two weeks? 16:41:40 asn: if I drop/postpone other stuff, yes. 16:41:40 i think we shoul;d publish sooner than later. 16:41:47 as karsten said, there are always going to be results to write about here. 16:41:54 so we could write another blog post in 2 months or so. 16:41:55 ok, ill come up with my own independent estimate of total traffic numbers, and karsten can do the analysis he considers necessary as ell 16:41:58 but yes, a week sounds acceptable. I think. 16:41:59 I'm starting more things than finishing. that makes me nervous. that's all. :) 16:41:59 I'm asking why it has to come out way before the report? 16:42:15 the report is out. 16:42:20 What's the rush on this blog post? 16:42:27 it's two different reports. 16:42:32 syverson: tbh there is no *real* rush 16:42:57 I'm willing to chill here, and give it as much time as it needs. 16:42:58 So why not wait for comfort as long as it doesn't stretch to say a month? 16:43:01 i'm just afraid that it will get super postponed. 16:43:30 karsten: what do you think? 16:43:33 Set a deadline to post it (three weeks?) and then go with what we have then. 16:43:34 we can also post to tor-dev@/tor-relays@ that we have this report, and do the blog post in a week or two. 16:43:37 i remember you wanted to get it out RSN 16:43:54 we told relay operators to tell them some results by mid-january. 16:43:59 yes that's true. 16:44:05 I feel we should tell them what we did with the data they gave us. 16:44:12 i agree 16:44:20 how do you feel about what you just suggested/ 16:44:27 sending tor-dev mail now, doing blog post in some weeks? 16:44:35 works for me. 16:44:40 But that could be message to tor-relays, which is quite different from a blog post. 16:44:41 OK. Let's do this way then. 16:44:48 ans: GMTA. 16:44:55 grr asn 16:45:25 OK. 16:45:30 That sounds good to me. 16:45:38 karsten: you want to send the email, or should I? 16:45:45 Aaron, any objections? 16:45:50 we can use parts of the blog post draft. 16:46:25 * karsten waits for ohmygodel to object or not object. 16:46:55 but assuming ohmygodel is okay with this, would you mind sending it, asn? 16:46:59 ok 16:47:12 will do 16:47:21 next topic? 16:47:32 HS terminology? 16:47:37 * karsten assumes ohmygodel processes some extra-info descriptors in the background.. :) 16:47:57 I'm fine with the terminology that ohmygodel suggested in that thread. 16:48:06 sorry my connection is flaky 16:48:11 ohmygodel: do you need backlog? 16:48:21 yes please 16:48:26 So I had this paper with saint where we talked about different terminology and why. 16:48:26 * asn waits 16:48:49 ohmygodel: sent. 16:48:54 last think i heard was (asn: lets do this then) 16:49:01 I've sent it to some of you and can send it to others.(not released yet of course). 16:49:06 muchas gracias 16:49:23 Getting ready for Valencia I see ;) 16:49:40 syverson: ok 16:49:41 jaja 16:49:54 OK? 16:50:00 ok, as in "please proceed" 16:50:03 please implement support for win98, instead of insecure linux. 16:50:11 (i have not rcvd or read the paper) 16:50:42 I can send it to you. (Please email me a reminder or I'll forget.) 16:50:48 (read backlog: blog plan sounds good, i will send my own numbers asap) 16:51:32 ok 16:51:40 ohmygodel: so what about HS terminology? 16:51:41 ohmygodel: great. 16:51:49 syverson: i would not describe that paper as having much discussion abuot terminology 16:52:09 i like the terms you decided 16:52:16 No it just uses other terminology and motivates doing so. 16:52:30 i'm not sure if they are the best one. but I'm not good with english to think of better ones. 16:52:39 I've personally adopted onionspace lately, as a replacement for darknet. 16:52:42 asn: i have received little feedback on changing the words we used in memex to describe hidden services 16:52:44 i agree that they could be improved 16:53:36 ok 16:53:56 yay! 16:53:56 i also like “onion services” as a general term that should be used most often 16:53:56 syverson and i had a discussion about having the shorthand for “encrypted services” be either “direct onion services” or “protected services” 16:53:56 anyway, any suggestions about how to proceed ? 16:54:03 I think a big one is to distinguish servers that put out their own ciricuits to get reached vs. ones that require a tor protocol to connect to them from someone elses circuit. 16:54:16 we can move the discussion elsewhere if youd like 16:54:38 ohmygodel: well, if it's just the lingo for the memex people, feel free to keep it in that list. 16:54:59 I was actually thinking more onion direc than direct onion. We also need a better term, something like bliaterally protected onion circuit for the current HS type case. 16:56:01 But of course more terse. 16:56:15 we could have an etherpad brainstorming options and then vote 16:56:15 we could simply discuss options and individually decide what were going to use 16:56:15 id at least like to get us in agreement, but maybe it is a time to get more tor people on board 16:56:15 i think you know more about how well that would work than i do 16:56:15 syverson: boo to “onion direct”, haha 16:56:57 OK this can degenerate quickly to watching Paul and Aaron argue. Nobody wants to see that. (ask Rob). 16:57:22 i don't find much value in voting between memex people. or even between Tor people just yet. 16:57:40 if you hope this lingo to be adopted by everyone, I'd suggest you start a thread in [tor-dev]. 16:58:04 I think a big question here, is "When and how to do the name migration" 16:58:17 I suggest that some of us thinking about design changes and uses talk to each other and we can then use terms that make sense. We can put out a blog post or a tor-dev discussion if that makes sense. 16:58:42 Product branding is a pretty big thing, and I'm not sure if a mailing list post or even a blog post would be sufficient. 16:58:47 Most useful terminology comes from people coming up with it to do stuff vs. committee decisions. 16:59:04 The Next Gen HS project, might be a good time to do product branding. When the onion addresses change to be bigger. 16:59:10 But this is not really SponsorR scope anymore. 16:59:11 my two cents, I do think that HS users/ops are actually best suited here to help out on a new name instead of devs deciding the coolest name 16:59:24 exactly 16:59:45 But we're talking about doing things with what we now call HSes that are largely unlike current use. 17:00:07 dgoulet: i sort of disagree in that developers have a better idea of the important technical distinctions to make 17:00:29 (As the hour is closing in, are there more discussion topics? 17:00:31 and also they probably talk about them the most.. 17:00:33 ) 17:00:48 ohmygodel: I disagree :) but we can talk on that other times 17:01:01 asn: to close this discussion, how about 17:01:01 i update the terminology list 17:01:06 What we are going to be doing next week might be a good topic. 17:01:46 on a wiki somewhere 17:01:46 and leave it at that 17:02:03 i'm fine with that. 17:02:07 depending on what's your end goal that is. 17:02:11 but that might be useful for the future 17:02:15 that is, a prepared wiki page. 17:02:36 at this point, im willing just for there to be some thought into better terms, and an awareness of what other people mean when they use these new terms 17:02:46 ok 17:02:49 then that sounds good to me. 17:02:54 I think it's important that developers distinguish the concepts, and maybe suggest names. whether users will like them or others is important, of course. 17:03:21 thanks for moving that discussion forward, ohmygodel. 17:03:32 true. i think it's very important. 17:03:56 so ok, should we close this meeting by finding out what we Tor folks should be doing next week 17:03:59 ? 17:04:09 I think you karsten have an idea what you will be doing. 17:04:10 ill attach this to our sponsor r page so that its public 17:04:10 sounds good 17:04:15 dgoulet: are you good for the next week? 17:04:21 sure. I'll look into percent-of-traffic math, and then read that other tech report and tweak it. 17:04:32 ack 17:04:33 ohmygodel: this? 17:05:02 I have a good amount of mail backlog to do. And some little-t-tor work with the feature freeze coming up. 17:05:03 yes will stop a bit litlle-t tor stuff and continue performance/reachability 17:05:10 syverson: “this” = wiki page with new suggested terminology (including multiple options for some things) 17:05:15 But I will have a day or two to do SponsorR work, what do you think I should be doing? 17:05:29 Should I start work on the security section? 17:05:36 Or on the opt-in section? 17:05:41 whatever you enjoy most? 17:05:45 I think I should start work on these if we hope to do anything in two months. 17:05:48 but I'm not sure where. 17:06:00 ok 17:06:03 asn: is anybody working on the new stats? 17:06:12 hm 17:06:31 work as in write proposal or write code? 17:06:31 karsten would be that person I guess, but now he is doing the % math. 17:06:38 maybe work as in "decide" 17:06:58 so, lead discussion to decide. 17:07:17 btw, I also need to clean up sources for the extrapolation tech report and push them. 17:07:21 i could be that person, but it probably means that I won't do any security/opt-in stuff. 17:07:24 but that's ok maybe. 17:07:29 this goes back to starting more things than finishing.. 17:07:52