16:02:23 <asn> #startmeeting SponsorR
16:02:23 <MeetBot> Meeting started Tue Feb 24 16:02:23 2015 UTC.  The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:02:27 <asn> hello friends
16:02:30 <asn> who is here for this meeting?
16:02:36 <karsten> hi!
16:02:39 <armadev> i am here
16:02:41 * syverson is
16:03:02 <asn> great
16:03:08 <asn> aaron is not attedning this one I've heard
16:03:24 <dgoulet> hello
16:03:27 <syverson> Right he's at a talk at Georgetown.
16:03:31 <asn> so let's go as usual with a small status report, and follow with discussion.
16:03:36 <asn> so during the past week
16:04:12 <asn> I looked a bit over #8243 , which is about making it harder to get the HSDir flag
16:04:28 <asn> we recently decided that requiring the Stable flag, might be a wise idea
16:04:51 <asn> so that people who cycle through many identity keys on a single relay, have a harder time inserting themselves int othe hash ring.
16:04:57 <asn> they will now have to wait a few days till they get the Stable flag.
16:05:11 <asn> I also opened #15008 about the opt-in HS publishiing iodea.
16:05:30 <asn> It seems that it's a pretty controversial idea, and many people suggested alternatives
16:05:55 <asn> Finally, I sent a mail to Roger about what we should be doing in the future with HS stats
16:06:04 <asn> since we were a bit confused on how to proceed here.
16:06:25 <asn> Roger suggested a few stats that we could develop,  while at the same time working on stats aggregation schemes.
16:06:33 <asn> It sounds like a plausible idea. Maybe.
16:06:39 <asn> I would like to discuss more during Valencia.
16:06:41 <asn> And that's that from me.
16:06:45 <asn> Whos next?
16:06:51 * karsten can go next
16:06:51 * syverson can go
16:06:54 <asn> karsten: please
16:07:01 <karsten> ok.
16:07:16 <karsten> I refactored and documented the #13192 code that is supposed to run on Metrics.
16:07:23 <karsten> it's waiting for a review.
16:07:41 <karsten> I also wrote a patch to add the new hidserv-stats to dir-spec: #15013.
16:07:43 <Yawning> 2
16:07:45 <asn> ah didn't know. ok.
16:07:49 <karsten> that's all.
16:08:05 <karsten> you didn't know it needs review?
16:08:06 <asn> ah that's #13192. not the java code. i did know that.
16:08:12 <asn> :)
16:08:22 <asn> yes #15013 is on my radar.
16:08:34 <karsten> cool!
16:08:35 <asn> who wants to go next?
16:08:57 * dgoulet here
16:09:08 <asn> deathrow1: go!
16:09:11 <asn> dgoulet:
16:09:13 <asn> (next is syverson)
16:09:24 <syverson> Aaron Johnson, Rob Jansen, Nick Hopper, Aaron Segal and I submitted our PeerFlow paper last night. Last week was pretty much that. Aaron sent a link to some of you.
16:09:35 <asn> aha
16:09:37 <dgoulet> (holding)
16:09:45 <asn> dgoulet: (hold it in)
16:10:01 <syverson> Ah you meant next after dgoulet. Sorry.
16:10:08 <dgoulet> syverson: go on ;)
16:10:11 <asn> syverson: it's ok. please proceed
16:10:40 <syverson> That's mostly it. The draft isn't even submitted for pub release yet, so please don't redistribute..
16:10:45 <asn> ack
16:10:49 <syverson> Happy to talk about it in Valencia.
16:10:51 <syverson> Done.
16:10:52 <asn> will need to read.
16:11:02 <asn> ack thx
16:11:03 <asn> dgoulet: please
16:11:06 <dgoulet> ok
16:11:40 <Sebastian> nickm: ideas in which direction to take #15015?
16:11:49 <dgoulet> so great battle with #14847 but I think we have got to a almost final point this morning with armadev, I have most of the code in little-t tor for it also
16:12:03 <asn> ack
16:12:24 <dgoulet> atagar has implemented hs desc. parsing in stem which is awesome because we can then use that for our hs health tool that I should start designing in a matter of days
16:12:40 <nickm> Sebastian: should fix in 0.2.7.  One option to not bind ports if options->cmd != RUN_TOR.  (identifiers approximate)
16:12:43 <atagar> armadev: 'wow, there is a python-stel rpm for rhel' => Yup! I've been really delighted at all the packaging folks that have shown up to help. It's now available on lots of distros. :P
16:12:46 <dgoulet> that's about it for R stuff
16:12:47 <atagar> https://stem.torproject.org/download.html
16:12:48 <nickm> Sebastian: not sure how ugly that would make the code though
16:12:52 <asn> thx dgoulet
16:12:56 <asn> armadev: anything to report?
16:13:05 <armadev> asn: yes
16:13:17 <armadev> a) i read the tech report and blog post. good stuff.
16:13:28 <asn> oh yes blog post. omg.
16:13:29 <armadev> i think we're ready to post. but i think there were some journalists that we wanted to answer the questions of first, to be polite to them.
16:13:42 <armadev> somebody should do that. it could be me if it it has to be.
16:13:49 <asn> you mean Patrick?
16:13:57 <armadev> yes, i think i do. i don't know if i mean other people too.
16:14:06 <armadev> i'd have to go find out what my mailbox says.
16:14:13 <asn> i thought that puffin was handling him.
16:14:17 <asn> but maybe not.
16:14:23 <armadev> puffin does not know the answers to his questions
16:14:35 <armadev> we, the technology people, need to play an active role in explaining things to journalists
16:14:36 <asn> I answered his questions to puffin
16:14:49 <armadev> ok. maybe it is handled then. somebody should find out. sounds like you!
16:14:51 <asn> and had puffin relay my answers to him. which is incredibly stupid on one hand. on the other hand, journalists omg.
16:15:01 <armadev> well, i did not see any answers.
16:15:02 <asn> ok i will find out.
16:15:28 <asn> i think he asked where the .5% figure comes from.
16:15:30 <karsten> thanks, asn. this blog post is hard work.
16:15:34 <armadev> b) helped dgoulet with hsfetch design. this was more complicated than either of us had realized, mainly because tor clients don't actually ask for a hidden service descriptor using the hidden service name.
16:15:47 <asn> anyway w/e i'll see what I can do with patrick
16:15:49 <armadev> c) answered asn's mail about where to focus in the future. research question: is there any plausible way to measure churn of onion services?
16:16:18 <armadev> d) moved a bit forward on the hidden service advocacy consortium idea -- i talked to the securedrop people last week about getting a blog post from them.
16:17:05 <armadev> my plan in a nutshell is to gather a pile of advocacy people together -- rainey, the securedrop person, jeff moss, the facebook guy, some more, to form a club whose goal is to make onion services sound less evil to the world
16:17:34 <asn> sounds good.
16:17:38 <armadev> and then e) there was some funding excitement last week, where it looked for a while like we didn't have any funding for this anymore, but now it looks like we do and it was just a misunderstanding, i hope.
16:17:44 <armadev> .
16:17:46 <Sebastian> nickm: I think it would make it very ugly because there are lots of places (don't open port, don't switch users come to mind. If those are it then maybe we're good)
16:18:05 <asn> ok
16:18:05 <Sebastian> but my intuition is that there are more things if we think harder
16:18:06 <asn> thx armadev
16:18:11 <asn> so that's that for the status reports.
16:18:12 <syverson> I'm supposed to hear during Tordev if my paper on that area with saint got in in case that's relevant.
16:18:15 <Sebastian> probably some of the debuggerattachment stuff
16:18:18 <asn> what would you like to discuss now?
16:18:36 <asn> tbh with Valencia coming up, I feel like discussing stuff there might be more fruitful. but this might be wrong.
16:18:43 <asn> I need to answer to Isabela for one.
16:18:55 <armadev> maybe we brainstorm topics people want to be sure to hit in valencia?
16:19:00 <karsten> what stuff should we read to make valencia discussions more useful?
16:19:03 <armadev> the isabela one is a good one
16:19:04 <dgoulet> yeah Isabela also
16:19:29 <dgoulet> is "isabela" in here *the* Isabela? :)
16:19:35 <armadev> syverson: you have accepted that some people won't be prepared to discuss the peerflow paper in valencia because they didn't get a copy?
16:19:36 <Yawning> ?
16:19:39 <armadev> dgoulet: yes
16:19:44 <asn> karsten: dgoulet: you want to use a pad to answer to isabela? or should I just do it?
16:19:52 <asn> and is there anything I should definitely mention to her?\
16:19:56 <asn> athat I would forget?
16:20:04 * karsten re-reads her mail
16:20:12 <asn> i'm hoping to read a bit of peerflow before going to valencia
16:20:26 <dgoulet> asn: I didn,t get any email from her :(
16:20:29 <asn> yeah
16:20:33 <asn> she didn't CC you.
16:20:40 <syverson> armadev: I'll send you a link. Also to anyone else reasonable, but would rather not post to a publicly readable list.
16:20:50 <asn> these were her questions:
16:20:51 <armadev> asn, can you send her the proposal, so she has context?
16:20:51 <asn> * how are we with that list of things listed to be done by April?
16:20:52 <asn> ** for the things that aren't done yet, do we have a sense of what
16:20:52 <asn> should be priority? (what we want to get done for sure by April)
16:20:52 <asn> * can you look here
16:20:54 <asn> (https://trac.torproject.org/projects/tor/wiki/org/process/IsabelaNotes#SponsorR)
16:20:57 <asn> and let me know if these are the list of people working on this
16:20:59 <asn> project?
16:21:02 <asn> * does the team meets with any frequency? Anything you can share on
16:21:04 <karsten> asn: hmm, it might be easiest if you replied, rather than us coordinating on what we want to answer first.
16:21:04 <asn> how the team is currently organized would be helpful
16:21:07 <asn> armadev: ah yes
16:21:09 <syverson> Who's Isabela or do I want to know?
16:21:10 <asn> armadev: good one
16:21:16 <armadev> syverson: nearly our new project manager
16:21:29 <syverson> Ah thanks.
16:21:32 <asn> karsten: yes ok.
16:21:56 <asn> i should tell her that one of the issues with this sponsor
16:22:02 <dgoulet> asn: ack thanks for the info
16:22:06 <asn> is that apart from the normal work we do
16:22:17 <asn> they also expect people to attend their multi-week workshops
16:22:19 <asn> every few months
16:22:31 <asn> i'm not sure how she could help wit hthis.
16:22:39 <dgoulet> armadev: oh on that ^, is she scheduled to come in april?
16:22:46 <armadev> she isn't
16:23:04 <armadev> i'm not sure if she should be. i'm not sure whether it's a good use of her time. what do you think?
16:23:23 <armadev> i more want her to help all of you do what you want to do, more organizedly
16:23:25 <dgoulet> armadev: maybe not indeed
16:23:51 <asn> yes, it was also my understanding that the workshops need technical people.
16:23:52 <armadev> asn: well, she could help in that it produces periodic self-imposed deadlines that we'd like to plan for and then meet.
16:24:11 <asn> that's for the worskshops?
16:24:13 <asn> or in general?
16:24:25 <armadev> asn: i am hoping she will get good at helping people answer questions like "ok, what can we have done by apr 10?"
16:24:31 <asn> sure
16:24:31 <syverson> armadev: workshops = QPR?
16:24:34 <armadev> yes
16:24:35 <asn> i'm sure she can help in general.
16:24:58 <asn> i'm also hoping she can take over the spreadsheet actions if that makes sense.
16:25:03 <asn> but w/e
16:25:09 <asn> i think we have exhausted the isabela topic
16:25:12 <asn> or we want to talk more?
16:25:33 <dgoulet> we'll sit down with her in a week so we can probably move on for now
16:25:40 <asn> do you want to talk about valencia topics?
16:25:49 <asn> where we enumerate many of them, and then we only do 2-3 in the end?
16:25:59 <asn> there are already various SPonsorR-related sessions in https://trac.torproject.org/projects/tor/wiki/org/meetings/2015WinterDevMeeting#SessionsNotes
16:26:15 <asn> I will also add the "Opt-In publishing" thing as a session
16:26:38 <asn> maybe also peerflow?
16:26:44 <dgoulet> asn: yup peerflow
16:26:54 <asn> maybe also "who the hell goes to these meetings on July?"
16:27:24 <dgoulet> asn: ahahah yeah that is a fun one
16:27:59 <armadev> yeah. in april we will need to assess how much we need to show up in july. a lot of that assessment will be by david since i will miss most of april.
16:28:14 <dgoulet> asn: I think the list now is good one, broad enough, especially with isabela bootstraping that won't be overwhelming and probably enough for us to get on going
16:28:36 <asn> OK.
16:29:02 <asn> What else would you like to talk abut now?
16:29:14 <asn> We can brainstorm about ways to measure the churn of hidde nservices if you'd like.
16:29:17 <armadev> while we're looking at topics, i'd just like to call out again my research question around measuring churn of hidden services. so far as i know there are no easy ways, now or post rend-ng, with or without aggregation, to measure it.
16:29:29 <armadev> right, thta
16:29:33 <asn> i've been trying to think,
16:29:34 <dgoulet> yessss
16:29:35 <asn> if we get anything useful
16:29:48 <asn> by having relays report the number of hidden srevices that stopped publishing descriptors to them prematurely
16:29:57 <asn> during the previous measurement period.
16:30:13 <armadev> asn: or the number that showed up after the period started
16:30:18 <asn> that basically tells you how many 24-hours unstable hidden services ther eare.
16:30:38 <armadev> or just how many publishes happened out of the 24 they expected (23? fencepost counting is hard)
16:30:39 <asn> armadev: how does this one work?
16:30:46 <karsten> and this time we try to use those data before gathering them. ;)
16:30:52 <syverson> Right. Depends what the "it" is you're measuring. Presumably just churn in onion namespace.
16:30:53 <armadev> asn: well, if you get a publish, and it's not the beginning of the interval, you know they were missing before that.
16:31:05 <asn> technically, it's not exactly 24 though. it's about the previous measurement period. not many HSes will align wioth our measurement period.
16:31:17 <asn> armadev: maybe they just started publishing to you
16:31:30 <karsten> but we know when they should start publishing to us.
16:31:32 <armadev> because of relay churn?
16:31:45 <armadev> in that case we'll have false positives if a relay moves out of the chosen 6 before the 24 hours are up
16:31:53 <asn> how do we know when they should start publishing to us?
16:31:59 <asn> doesn't each HS has its own publishing cycle?
16:32:08 <armadev> asn: correct, but the publishing cycle is deterministic by the name.
16:32:09 <karsten> yes, but we can calculate that for each HS.
16:32:29 <armadev> sadly, these are all things that will go away with the rend-ng design.
16:32:33 <karsten> the same holds for finding out why they stopped publishing to us.
16:33:00 * karsten puts rend-ng on the reading list, too.
16:33:26 <special> is there an explanation somewhere of why churn is a useful metric to have?
16:33:30 <armadev> i can imagine assessing churn right now by running a bunch of hsdirs and comparing data between them
16:33:39 <armadev> post rend-ng, i cannot imagine any way of assessing churn, even rude ones.
16:34:02 <armadev> special: well, out of the 27000 dark onion services.. are they the same each day? or are there 27000*7 in a week?
16:34:28 <special> those are questions it would answer, but I'm still not connecting to how it is _useful_
16:34:29 <asn> armadev: maybe special doesn't share your curiocity about random hidden services.
16:34:50 <armadev> special: basically, it would seem that our statistics observe a tiny fraction of onion space. and we don't have any handle on how to get a better handle on the rest.
16:35:07 <armadev> i want to be able to recognize when new protocols become popular, or stop being popular
16:35:33 <armadev> i want some baseline stats that tell me about the general state of onion space, so when it changes, a) i can notice, and b) i can have some chance at guessing why it changed.
16:35:46 <armadev> imagine if we didn't have any relay stats. or no user stats.
16:35:59 <armadev> then when turkey is about to happen, we have no way to know.
16:36:06 <armadev> and when it did happen, we still have no way to know.
16:36:07 <syverson> Also I don't think we know yet how big a fraction of onion space vs. onion namespace we're actually getting, at least not yet.
16:36:28 <asn> syverson: what do you mean here?
16:36:34 <syverson> E.g. because of churn.
16:36:51 <asn> i'm not familiar with the distinction of onion space and onion namespace yet.
16:36:53 <armadev> ah you think a given service might have a new name periodically but "be" the same underlying service?
16:36:59 <asn> ah
16:37:00 <asn> i see
16:37:55 <syverson> That could be some of it. How much is people setting up 4 onion services and abandoning the ones they screwed up when they get one as they want it for instance.
16:38:13 <armadev> oh, because they're trying for cute names
16:38:26 <armadev> in theory they don't need to actually run the ones whose names they don't like. but who knows.
16:38:32 <syverson> Or just cause they realized they leaked something or...
16:39:02 <asn> 16:31 < armadev> asn: well, if you get a publish, and it's not the beginning of the interval, you know they were missing before that.
16:39:05 <armadev> i also want some handle on whether a lot of onion services are single use, a la onionshare
16:39:18 <asn> so it's possible to learn whether a publish is the first or the second or the last publish of a hidden service for that publish cycle?
16:39:26 <armadev> asn: i think it is currently yes.
16:39:47 <armadev> asn: you compute the time interval for that service for that day, and see whether you should have gotten a descriptor an hour ago or not.
16:39:50 <asn> because bgy the time the HSDir needs to publish statistics, the HS might not have finished its publish cycle yet.
16:40:03 <asn> ah i see.
16:40:05 <asn> yes plausible.
16:41:25 <dgoulet> I'm curious if there are actually descriptors that are on purpose published to hsdir that aren't suppose to store it or how many fetches an HSdir get for desctiprtor it's not suppose to have either
16:41:43 <armadev> interesting.
16:41:51 <dgoulet> (might not be useful but I want to explain why I have so many fetch request on my relay that fails...)
16:42:06 <armadev> this is related to my question about whether relay churn influences whether parameters like "6" are good choices.
16:42:14 <special> dgoulet: it's very likely that the answer to this is "torchat" (and things that behave like torchat)
16:42:15 <dgoulet> right reachability issue
16:42:15 <syverson> Also hard to distinguish single use from something used periodically and off otherwise. That seems quite likely for personal applications.
16:42:22 <armadev> dgoulet: is there a way to phrase the failed descriptor fetch thing as a research question?
16:42:39 <armadev> special: ah, because i thought it was very likely that the answer is "dead botnet c&c"
16:42:53 <dgoulet> armadev: I guess you could phrase it in a way that involves botnet reasearch
16:42:54 <special> armadev: there is only one of those, compared to "a lot" of torchat services
16:42:55 <asn> [btw, is there anything else that people want to talk about before the end of the hour?]
16:42:57 <armadev> can we design an experiment to figure out which it is?
16:43:21 <dgoulet> special: torchat, interesting
16:43:42 <asn> yeah torchat is very ephemeral
16:44:02 <special> I notice, though..
16:44:04 <armadev> dgoulet: you know the tiny shadow snippet that i've been giving people for them to run alongside their tor, while doing onion service crawling? and you know how stem is getting better here? can we write down clear instructions to use stem instead of the tiny shadow snippet?
16:44:12 <armadev> dgoulet: if so, is there a ticket for this?
16:44:38 <special> this conversation is about collecting aggregate stats on things like churn, but the questions you're asking are about what services are hosting, how clients are using them, and why
16:44:47 <dgoulet> armadev: for sure stem is better suited I think, HS desc parsing is there and we have #14845 also to query the cache directly
16:44:57 <dgoulet> armadev: not sure a ticket exists for the "tool" you want
16:45:01 <armadev> special: for torchat designs, to check presence of buddies, i've always thought a better design is to maintain connections to all your buddies, and try to rebuild if they go away. rather than re-introducing to all your buddies every time period. agree/disagree?
16:45:32 <special> armadev: I believe it does maintain connections. The trouble is that when it doesn't have a connection, it will try every time-period to make one.
16:45:32 <armadev> dgoulet: ok. we need to write clear instructions for people who don't know what tor is, to get their thing going. think the hyperion gray folks.
16:45:56 <nickm> Has a TBB alpha with 0.2.6.3-alpha come out yet?  If not, when will it?
16:46:00 <nickm> I want to let that be out for a little while before I call 0.2.6.4-rc
16:46:01 <armadev> special: that seems wasteful if both sides are trying it. why not trust that the other side will try it when it arrives.
16:46:11 <special> armadev: indeed!
16:46:15 <qwerty1> special: right, it seems sketchy and i also don't see any way this stuff benefits tor users
16:46:22 <dgoulet> armadev: in a nutshell, they seemed to want a precise reason of the hs failure right?
16:46:26 <armadev> special: but if both sides trust that the other side will do it, and they race to being patient....
16:47:06 <armadev> dgoulet: well, that's part of it. also they just wanted to log useful stuff to a log so later some tool could analyze the log to say which onion services existed, which didn't exist, and which ones failed where in the rendezvous process.
16:47:21 <asn> qwerty1: special: someone needs to write a blog post about SponsorR soon.
16:47:28 <asn> to kill the paranoia.
16:47:28 <dgoulet> armadev: ack
16:47:36 <armadev> dgoulet: and that ties into the "we give the same end-stream-reason in wildly different situations' bugs
16:47:39 <asn> or increase it.
16:48:10 <dgoulet> armadev: yeah, I can probably come up with a good doc about that in a reasonable amount of time
16:48:25 <dgoulet> asn: +1
16:48:34 <asn> qwerty1: special: i'm quite happy that you two people are aware of this sponsor, and are raising your concerns.
16:48:39 <special> asn: well, the question I would ask for every one of these HS stats is "does this provide useful information, or is it only interesting information?"
16:48:41 <Yawning> asn: Por que no los dos?
16:48:49 <special> because "arma's curiosity" might very well be a valid adversary for hidden services ;)
16:49:12 <asn> do you consider the two stats we recently published as useful?
16:49:21 <armadev> the thing is, i want to be able to answer future questions, and i don't know what they will be yet
16:49:21 <special> which, exactly?
16:49:22 <dgoulet> the tech report lists a bunch of "pros" for each stat but not all have useful pros
16:49:28 <asn> fuck the blog post is still not up. so you might not even be familiar.
16:49:38 <armadev> so i want to guess what they might be, and collect baseline stats about what in general happens in the tor network
16:49:47 <armadev> so when things change we have some prayer of noticing even that it *did* change
16:50:07 <asn> armadev: have this happened with other stats s ofar?
16:50:38 <armadev> asn: what if we didn't have directory download stats? we would not have been able to guess that the new botnet clients were indeed actual clients.
16:51:03 <armadev> asn: all we knew was that there was a lot more bandwidth load on the tor network. but heck, what if we didn't have bandwidth load stats? all we would know is that relay operators were complaining.
16:51:23 <armadev> and we still don't have cpu load stats. they sure would have been helpful there.
16:51:45 <armadev> asn: and we still don't have any idea, from the stats, that the botnet had something to do with hidden service. we had to read it in ralf's paper.
16:52:10 <armadev> when something goes weird with the tor network, i want to go look at our graphs and try to guess what went wrong.
16:52:46 <armadev> because things do go wrong and the tor network is not really robust
16:53:39 <asn> ack
16:54:01 <meejah> icodemachine: hi. if you have a question, best to just ask it so i can answer when i see it?
16:54:12 <asn> So anything else to discuss?
16:54:39 <karsten> asn: how do we move on with putting graphs on Metrics?
16:54:42 <armadev> asn: it does seem like an outline for a "why understand the tor network, and hidden services in particular" explanation would be a good next step
16:54:48 <armadev> karsten: ah yes, i wanted this too.
16:55:04 <asn> karsten: tell us about it.
16:55:08 <karsten> armadev: agreed that such a document would be useful.
16:55:09 <asn> karsten: what is needed here?
16:55:15 <karsten> asn: review.
16:55:20 <asn> ok.
16:55:21 * karsten finds the link.
16:55:25 <asn> did you add docs?
16:55:29 <asn> supposedly that was the blocker there.
16:55:33 <karsten> plenty of docs
16:55:36 <asn> ok
16:55:37 <karsten> and refactoring
16:55:39 <asn> so the java thing is ready for review.
16:55:47 <karsten> it is.
16:55:48 <asn> let me suggest we walk over the code in valencia?
16:55:57 <karsten> hmmm, sure, why not?
16:56:00 <asn> great.
16:56:03 <asn> let me note it down.
16:56:10 <asn> i think it will be better with both of us on it.
16:56:39 <karsten> https://gitweb.torproject.org/karsten/metrics-tasks.git/tree/task-13192/src/java?h=task-13192-metrics
16:56:43 <asn> ack
16:57:02 <icodemachine> meejah: Yeah sorry ;). Anyways, i wanted your feedback on my project idea
16:57:02 <asn> OK.
16:57:08 <asn> Are we done here?
16:57:34 <armadev> is there a list somewhere of what we plan to do by april?
16:57:43 <asn> yes
16:57:50 <asn> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR#ProjectsfromJanuarytoApril2015
16:57:56 <asn> s/plan/hope//
16:58:11 <asn> we are on track with some of them, not on track with others.
16:58:43 <nickm> ((Patch workshop in 60 minutes))
16:58:44 <asn> i haven't had any time to work on security so far. or really work on the opt-in thing, since what's needed is discussion it seems.
16:58:55 <meejah> icodemachine: okay; did I miss an email, or...?
16:58:59 <asn> karsten: btw, will anything break on our calculations, if we increase the requirement for getting the HSDir flag to having the Stable flag?
16:59:04 <asn> karsten: i mean our statistics extrapolations etc.
16:59:14 <syverson> asn: but we'll talk about those in Valencia right?
16:59:16 <asn> karsten: so basically there will be less HSDirs. about 1500 instead of 3000.
16:59:20 <asn> syverson: yes
16:59:21 <icodemachine> icodemachine: Yes, i sent you an email yesterday
16:59:31 <karsten> asn: should be fine.
16:59:37 <asn> OK.
16:59:51 <karsten> there might be strange results for a day or two, but should be fine.
17:00:05 <armadev> karsten: are there any relay identities that are weirdly close to another relay identity? like, somebody trying to "poach" all of the hsdescs that would go to one?
17:00:24 <karsten> that's something phw was looking at.
17:00:37 <karsten> as part of his sybil attack detector.
17:01:07 <armadev> ok. understanding relay churn more might help us in future design decisions. for example,
17:01:32 <armadev> we could imagine making which relay is the 'successor' to a given hsdir be a function of the descid
17:01:45 <armadev> so there is no such thing as poaching all of a target hsdir's descriptors
17:01:57 <armadev> basically a new hash ring for every descid
17:02:13 <armadev> (who knows, maybe the rend-ng does this)
17:02:57 <karsten> armadev: so, phw and I discussed relays that change their fingerprint frequently. not pairs of relays with close fingerprints.
17:03:18 <meejah> ah, i see it; sec
17:03:21 <armadev> ah. so this is a new thing to consider?
17:03:48 <armadev> if i were an attacking hsdir, i would pick a super stable relay, and snuggle up right next to it, so i get all its hdescs and it gets none.
17:04:05 <karsten> armadev: https://github.com/kloesing/SAD got that on my list.
17:04:14 <karsten> "Common fingerprint prefix: how many of the fingerprint bits match starting from most significant bit? This is relevant to detect attacks on the hidden service hash ring."
17:04:27 <armadev> ok
17:04:40 <karsten> not sure if phw looks at that for building his detector.
17:04:44 <karsten> but it's on a list somewhere.
17:04:49 <dgoulet> latest email from asn got replied today by DonnaC and dcf1 which got intersting thoughts
17:04:58 <dgoulet> 'Table of "Tor relay identity keys per IP address"'
17:05:05 <karsten> gareth replied too, but his reply was too big.
17:05:15 <asn> yes happy it got replies.
17:05:15 <dgoulet> oh
17:05:16 <karsten> I hope he re-sends.
17:05:34 <asn> also hooray for CCing [tor-assistants] it attracted dcf's attention
17:05:51 <asn> anyway guys
17:05:56 <asn> i'll call this meeting done for now.
17:06:29 <asn> armadev: the rendspec-ng does not do what you described above. i didnot entirely get what you described. i will try later with more brain.
17:06:35 <asn> #endmeeting