15:04:29 <asn> #startmeeting SponsorR
15:04:29 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:04:34 <asn> hello all
15:04:41 <asn> can I have a headcount?
15:04:45 <dgoulet> here!
15:04:50 <syverson> here!
15:04:57 <ohmygodel> yo
15:05:04 <isabela> here!
15:05:08 <karsten> hi
15:05:30 <asn> epic
15:05:43 <asn> and a combination of roger/nick seems to be around too
15:05:52 <asn> ok, so welcome to the sponsorr meeting
15:05:59 <asn> i imagine that we will spend less time briefing up today
15:06:03 <asn> and more time strategizing for the future
15:06:09 <asn> since we do plenty of the former during the dev meeting
15:06:26 * nickm is here too
15:06:44 <asn> 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 <asn> but we can handle this during the discussion phase
15:06:58 <asn> anyone has a status report?
15:07:09 <nickm> yo.
15:07:10 <asn> karsten: i'm curious how the metrics integration stuff are going, if they are.
15:07:24 <karsten> nickm: want to do a status report first?
15:07:31 <karsten> or should I respond to asn?
15:07:35 <nickm> I've been rereading the aggregation designs.  #1 would be easy to do, especially if it's a separate thing.
15:07:44 <nickm> karsten: IRC rules; let's all talk at once. :)
15:07:49 <karsten> heh
15:08:06 * karsten lets nickm finish
15:08:17 <nickm> 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 <asn> nickm: separate thing even on the relay side?
15:08:27 <nickm> y
15:08:47 <asn> like a separet software that relay ops would have to use?
15:08:55 <asn> that communicates with StatsAuths?
15:09:29 <nickm> 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 <asn> ack
15:09:37 <nickm> but doing this in the tor process is IMO nuts
15:09:44 <asn> ack
15:09:59 <armadev> woah. meeting. i will read backlog and then be here.
15:10:07 <ohmygodel> cool nickm
15:10:12 <asn> ok nickm. we can discuss this some more later.
15:10:15 <nickm> ack
15:10:15 <ohmygodel> i would be interested in helping you with those signatures
15:10:30 <asn> anyone else who did anything interesting the past few days?
15:10:39 <karsten> asn: well, to answer your question,
15:10:48 <karsten> I looked at the two things you and dgoulet found,
15:11:02 <karsten> and I think both need better documentation, but at least they are not bugs.
15:11:10 <karsten> thanks for the review, by the way!
15:11:13 <asn> ack
15:11:20 <dgoulet> good
15:11:20 <asn> peer reviewing that was fun
15:11:29 <karsten> glad to hear!
15:11:59 <karsten> (that's all from me re: status report)
15:12:07 <ohmygodel> nothing for me to report
15:12:08 <asn> what is left, after the documentation gets added?
15:12:14 <asn> to integrate it to the website?
15:12:27 <asn> to integrate the graphs to the metrics website, that is.
15:12:28 <karsten> move the code to metrics-web.git,
15:12:34 <karsten> deploy on yatei,
15:12:44 <karsten> add some html, some R.
15:12:56 <karsten> well, for the R part, decide what graphs to show.
15:13:17 <asn> ok sounds good
15:13:20 <karsten> not a crazy amount of work altogether.
15:13:24 <asn> keep me in the loop if you need more help.
15:13:28 <asn> ok, anyone else?
15:13:34 <asn> or should we move to discussion phase?
15:13:35 <karsten> yes, I'll ask for feedback on graphs, I think.
15:13:40 <syverson> me?
15:13:43 <asn> syverson: yes please
15:13:58 <armadev> i have some things to report. or at least topics to make sure we cover.
15:14:09 <asn> armadev: ok. you are in the queue.
15:14:10 <syverson> Not too much not discussed at dev meeting. Worked on paper w/ Griffin.
15:14:32 <syverson> In process got Juha to agree to include PGP field in JSON.
15:14:45 <asn> ( syverson: I added a note about oour guard lifetime discussion in #8240)
15:14:48 <syverson> So this should make such onion services more amenable to indexing.
15:15:14 <syverson> Also ohmygodel and I sighed up for the DARPA Brandeis proposers day.
15:15:19 <asn> you mean to the "here are my information" JSON that HSes can put on their web path?
15:15:33 <syverson> Not exactly sponsor R of course, but should end up being related.
15:16:01 <syverson> It should be listed in the files when one searches ahmia.
15:16:10 <syverson> That's about it.
15:16:11 <asn> ack
15:16:12 <asn> thx
15:16:18 <asn> armadev: please
15:16:55 <armadev> 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 <armadev> b) did ya'll see the mail from phil asking for input for the monthly report? is somebody on that?
15:17:20 <syverson> Yes.
15:17:34 <asn> yes i will handle that on the tor side.
15:17:35 <syverson> But I'm not the person you probably need a yes from.
15:17:44 <asn> will have something today
15:17:54 <armadev> 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 <qwerty1> karsten: is there meant to be a line for 'other' or 0.2.6 on https://metrics.torproject.org/versions.png ?
15:18:12 <armadev> 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 <karsten> qwerty1: I'll look after this meeting.
15:18:31 <armadev> they none the less want to continue calling it a 'privacy' panel though, for reasons i haven't pushed on.
15:18:39 <syverson> Is this a closed meeting? Can others attend? Who can I ask?
15:19:11 <armadev> 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 <armadev> 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 <isabela> armadev: I dont have @tp.o email
15:19:45 <syverson> Brian Sandberg I assume. And which Ryan?
15:19:56 <asn> isabela: ah
15:19:59 <Yawning> isabela: did you get your pgp key signed at valencia?
15:20:01 <armadev> 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 <asn> isabela: you will need to open a trac ticket for this
15:20:10 <asn> isabela: see for example this one https://trac.torproject.org/projects/tor/ticket/10113
15:20:15 <asn> isabela: for the information required
15:20:21 <isabela> asn: tx will do
15:20:35 <isabela> Yawning: yes for isabela@riseup.net email only
15:20:35 <armadev> re (d), pde wrote up notes here: https://trac.torproject.org/projects/tor/wiki/org/meetings/2015WinterDevMeeting/Notes/SecureServerRouting
15:20:43 <nickm> I have ideas about that.
15:20:45 <nickm> I should reply.
15:20:55 <nickm> Will pde mind if I reply on tor-dev?
15:21:01 <Yawning> isabela: that's fine, just need to have a signed key for the process
15:21:13 <asn> armadev: will read
15:21:20 <armadev> nickm: he will not mind
15:21:35 <ohmygodel> armadev: lets encrypt sounds very cool
15:21:42 <armadev> 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 <ohmygodel> it sounds like tor could really use short-circuited onion services
15:22:06 <asn> ack
15:22:08 <nickm> yes, lots of folks want that
15:22:10 <asn> let's move to discussion phase
15:22:26 <Yawning> is this where we talk about random onion service stuff including R, or just R
15:22:34 <asn> do you people have specific topics to discuss? please list them up.
15:23:07 <asn> 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 <nickm> Is it useful for me to try to hack up a stats aggregation thing in march? by april 15?  How useful?
15:23:14 <ohmygodel> - 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 <ohmygodel> - implementing anonstats
15:23:45 <syverson> nickm: my2c says it's important for July not April.
15:23:47 <asn> 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 <ohmygodel> - is the stats tech report published
15:24:11 <asn> isabela: no harm in trying one or two such meetings. maybe it will develop into something nice.
15:24:15 <armadev> 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 <isabela> asn: lets see how that go and maybe we can merge both meetings in the future
15:24:34 <asn> ohmygodel: i like all of these
15:24:47 <nickm> syverson, armadev: what should we have done in July?
15:24:53 <asn> - i also have some ideas on short-term statistics that we could do, till we figure out the top-down stuff
15:25:06 <syverson> 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 <asn> So let's talk a bit about anonstats. Since nickm brought it up and it's the current topic.
15:26:05 <armadev> 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 <ohmygodel> ok asn
15:26:18 <Yawning> armadev: ah ok
15:26:37 <Yawning> I updated #6411 with the next steps (beyond " I still need to write the docs for it")
15:26:50 <ohmygodel> 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 <asn> 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 <ohmygodel> this is anonstats1
15:27:05 <Yawning> 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 <nickm> Yawning: ok by me
15:27:32 <Yawning> and once that's done and the control spec diff is done, I will seek review for the branch
15:27:32 <asn> Yawning: I like.
15:27:55 <ohmygodel> asn: that list is easy
15:28:06 <nickm> so, anonstats1 is easy.  subsequent ones are harder, a bit
15:28:07 <ohmygodel> it is all statistics in our report that would be collected by HSDirs
15:28:12 <Yawning> 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 <ohmygodel> because each HSDir is the same, there is no anonymity leak in the numbers themselves
15:28:37 <armadev> can somebody provide a url to "anonstats1"?
15:28:39 <nickm> it could also help beyond sponsor R, and let us eventually compute network-wide totals while removing stuff from extrainfos
15:28:58 <asn> ohmygodel: makes sense
15:29:08 <asn> ohmygodel: i guess next question is "which questions it helps us answer"
15:29:09 <ohmygodel> https://lists.torproject.org/pipermail/tor-dev/2015-January/008086.html
15:29:18 <asn> AnonStats1 ^
15:29:25 <armadev> 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 <ohmygodel> the main question it helps answer is
15:30:52 <ohmygodel> “what is the distribution of client activity over onion services"
15:31:11 <ohmygodel> why do we care about that?
15:31:29 <qwerty1> i do not know
15:31:32 <ohmygodel> one reason is, it helps us properly explain onion services to the world
15:31:50 <nickm> define "distribution" in the case?
15:31:54 <ohmygodel> if there are lots and lots of onion services being used
15:32:03 <asn> is that the same as "total number of descriptor fetches"?
15:32:06 <ohmygodel> then its definitely not all silkroad v. N
15:32:12 <ohmygodel> asn: yes
15:32:16 <asn> ok
15:32:42 <armadev> 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 <asn> it's a bit like the gareth owen stat, but without mapping it to specific hidden services.
15:32:55 <armadev> great, that sounds better.
15:33:03 <ohmygodel> its actually the number of descriptor fetches per HSDir
15:33:18 <asn> somewhere between "number of hidden service clients" and "number of hidden service accesses".
15:33:18 <ohmygodel> we could break it down further if desired
15:33:31 <ohmygodel> we cant aggregate it any more without a more sophisticated protocol though
15:33:51 <asn> i can be persuaded that this is a useful stat. or maybe an interesting one.
15:33:54 <qwerty1> i2p has no such stats and they seem to manage fine
15:34:08 <ohmygodel> (and the HSDir is anonymous, as provided by AnonStats1)
15:34:25 <asn> are there other useful data that we could get from AnonStats1, that we can't get now?
15:34:31 <asn> qwerty1: ack
15:34:36 <armadev> qwerty1: no they don't, actually. i2p has approximately zero users.
15:34:36 <ohmygodel> asn: yes, there are
15:34:39 <asn> qwerty1: we talked a lot abou tthis during the valencia meeting
15:35:04 <ohmygodel> the intro point statistics in our tech report could potentially be collected
15:35:08 <asn> qwerty1: we have decided to examine stats more carefully
15:35:29 <asn> 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 <ohmygodel> however, because the IPs are selected based on consensus weight
15:36:09 <ohmygodel> the magnitude of the number alone could reveal its identity, thus linking its stats to the onion service it serves
15:36:48 <ohmygodel> 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 <ohmygodel> *to use it for
15:37:00 <asn> but what interesting stuff could IP stats tell us?
15:37:04 <asn> more than the HSDir stats that is.
15:37:20 <asn> it could tell us "how many clients got past the HSDir phase"
15:37:32 <syverson> 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 <armadev> syverson: do you differ by thinking it is important? or unimportant?
15:38:18 <syverson> I differ in thinking about how dangerous it is, and I think it could help us understand load etc.
15:38:29 <ohmygodel> 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 <ohmygodel> :_)
15:38:57 <ohmygodel> :^0
15:39:17 <asn> 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 <syverson> 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 <asn> may I post a few questions that I would like to see answered using top-down approach?
15:40:12 <syverson> asn: go
15:40:13 <ohmygodel> asn: IP statistics could be helpful in several larger research goals
15:40:36 <ohmygodel> including detecting botnets, communicating the value of onion services better, and improving performance
15:40:53 <asn> 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 <atagar> 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 <atagar> btw, good morning world
15:41:19 <federico3> o/ atagar
15:41:32 <asn> 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 <armadev> asn: add "if we need to cache hsdescs all day or just for an hour or something" to the list
15:41:49 <asn> yes
15:42:11 <asn> 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 <Yawning> hm
15:42:26 <asn> 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 <Yawning> isn't the bandwidth question really hard?
15:42:42 <Yawning> >.>
15:42:42 <asn> to see whether blending high with low latency is useful for us.
15:42:50 <asn> Yawning: yeah, I don't know if it's technically possible.
15:42:50 <armadev> what are high latency hidden services?
15:43:10 <asn> armadev: unclear. people want to have high latency anonymous publishing.
15:43:28 <asn> it's worth investigating whether it can be done in Tor.
15:43:33 <armadev> 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 <asn> 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 <federico3> asn: d'you think obfsproxy would be the right candidate for a DNS tunneling transport?
15:44:10 <Yawning> 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 <syverson> asn: current onion service usage? Cause that may not be very informative.
15:44:50 <asn> yeah I haven't thought about this problem enough to be able to form a productive sentence, I'm afraid :(
15:44:57 <asn> federico3: eeeehm maybe.
15:45:03 <armadev> syverson: true. we're building for the future we want, not the present we have.
15:45:14 <syverson> asn: the sentence is "we should do research" ;>)
15:45:23 <Yawning> dns that's actually dns is going to be kind of slow
15:45:31 <federico3> Yawning: *very* slow
15:45:53 <Yawning> 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 <Yawning> though that may be minor
15:45:58 <federico3> (but usually enough for fetching email, IRC, SSH)
15:46:02 <asn> these are the top-down questions I could think of so far.
15:46:15 <nickm> Yawning: cache-shitting might be _great_ for bridge discovery though
15:46:31 <ohmygodel> sounds great asn
15:46:41 <Yawning> nickm: yeah, I think some folks ran attacks to see how many people used iodine a while back
15:46:53 <ohmygodel> several of those hadnt occurred to me!
15:46:54 <Yawning> well, ran the analysis
15:46:59 <armadev> 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 <nickm> +1 on that list
15:47:14 <Yawning> +1
15:47:18 <ohmygodel> before moving onto writing the top-down list
15:47:23 <ohmygodel> can we close anonstats ?
15:47:31 <asn> yes
15:47:44 <ohmygodel> i want to say that
15:47:53 <ohmygodel> i agree that it need not be done by april
15:47:58 <ohmygodel> however
15:48:30 <ohmygodel> i would like to have a plan to have it done by june
15:48:37 <ohmygodel> assuming that we agree that it is worth it
15:48:48 <syverson> ohmygodel: anonstats1 no?
15:48:50 <ohmygodel> yes
15:48:54 <nickm> 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 <armadev> 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 <ohmygodel> so are we agreeing to move forward on this ? do we need a vote ;-)
15:50:06 <syverson> I vote we don't need one.
15:50:18 <armadev> i delegate my vote to asn. i haven't been following closely enough to know what i should think.
15:51:00 <syverson> I think the people to vote/decide are ohmygodel, asn, dgoulet, and nickm.
15:51:09 <armadev> sounds good to me.
15:51:13 <asn> i think I will go with abstention for now.
15:51:24 <asn> I will be able to vote more usefully after we have some more data on the top-down list.
15:51:24 <nickm> Hm. Part of me always wants to implement code. Part always wants to implement _other_ code.
15:52:15 <asn> 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 <syverson> Maybe since asn wants to abstain, we defer a week until the top-down list is fleshed out?
15:52:35 <ohmygodel> asn: if you want to postpone this decision until after we have a top-down plan, i am fine with that
15:52:44 <nickm> 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 <dgoulet> I would much prefer having the top-down list before deciding on anonstats1 proposal/implemenation, my 2 cents
15:53:18 <nickm> (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 <ohmygodel> nickm: sounds fun. can you explain a little more what you need from the formulae. maybe email?
15:53:41 <armadev> nickm: i think nick hopper was the one who told you it was easy? you might ask him
15:53:44 <nickm> ok
15:54:07 <armadev> 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 <ohmygodel> nickm: actually let me see if i can provide the description at the level this blog post gives for other schemes
15:54:28 <ohmygodel> then you can say if thats enough
15:54:38 <nickm> err, i could use even more, will send an email within 30 min
15:54:42 <ohmygodel> ok
15:55:03 <ohmygodel> so maybe we should instead talk about the top-down plan
15:55:06 <asn> armadev: seems so.
15:55:13 <asn> armadev: let's see how this goes.
15:55:42 <asn> fine with moving to top-down plan
15:55:56 <asn> fwiw, I also had a small list of statistics that we could do in the meanwhile
15:56:00 <asn> till we formulate the whole top-down thing
15:56:13 <asn> for example, I think statistics on HSDir attacks could be done now, without any extra little-t-tor code.
15:56:26 <asn> like identity keys per IP
15:56:36 <asn> and density of HSDirs in the hash ring
15:56:58 <asn> the "popularity of hidden services" paper has 5-6 heureistics that could be used to detect such attacks
15:57:03 <dgoulet> asn:  maybe we could do that in the hs health tool ?
15:57:19 <asn> i believe it's great to have this information on metrics.torproject.org so that they can be audited
15:57:23 <dgoulet> asn: because all this computation from (past/now) consensuses will be needed anyway
15:57:35 <asn> yeah maybe
15:57:35 <dgoulet> asn: and the goal is to publish it on metrics also
15:57:51 <asn> i recently learned that the hs health tool will eventaully be used on the real network
15:57:57 <dgoulet> yes
15:58:13 <asn> so I'm not very familiar with how that would actually work, or when would that happen.
15:58:16 <karsten> dgoulet: we should talk about data formats, collecting data, etc. at some point.
15:58:34 <dgoulet> asn: how about we schedule a discussion about it? :)
15:58:40 <asn> dgoulet: ack
15:58:41 <dgoulet> karsten: indeed, soon will request your help
15:58:48 <asn> ok
15:59:00 <asn> so you guys want to talk about top-down plan?
15:59:04 <asn> you have any ideas?
15:59:20 <armadev> 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 <ohmygodel> i think we should discuss this at a meta-level
15:59:34 <asn> 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 <ohmygodel> like, where and when and how will we write this
15:59:42 <asn> isabela: since our jargon use is quite extensive here.
15:59:57 <asn> armadev: ack
16:00:19 <asn> ohmygodel: "where": maybe it can be a different section of the stats tech report?
16:00:36 <asn> ohmygodel: "when": between now and july? maybe closer to now than july.
16:00:48 <ohmygodel> asn: that report should be frozen. i have pub release for it in its current form only
16:00:58 <asn> hah
16:01:17 <asn> different tech report I guess then
16:01:33 <ohmygodel> asn: hah indeed. imagine the press review of your hs blog post times 10. thats pub release
16:01:37 <karsten> I'd want to make that tech report better before publishing though.
16:01:51 <nickm> ohmygodel: sent
16:01:56 <ohmygodel> karsten: can we discuss that after this
16:01:58 <ohmygodel> nickm: ack
16:02:01 <karsten> ohmygodel: yup.
16:02:28 <asn> so I guess we can make a shorter new tech report about the top-down thing
16:02:36 <ohmygodel> asn: “when” should be quite fast IMO. before april certainly
16:02:53 <ohmygodel> this isnt hard. i can write up my ideas right now in about an hour
16:03:27 <ohmygodel> 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 <ohmygodel> an etherpad transitioned to the sponsor r wiki makes sense to me
16:04:02 <armadev> 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 <armadev> like, why is this an important question
16:04:30 <armadev> and how will answering it help us take some useful action
16:04:40 <syverson> armadev: true, but how does the tech report per se help w/ that?
16:04:56 <armadev> i'm just saying if we do this thoroughly we'll have some pages of text
16:05:00 <isabela> 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 <ohmygodel> armadev: i agree
16:05:18 <asn> 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 <syverson> d'accord.
16:05:36 <asn> 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 <asn> 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 <ohmygodel> asn: yes i agree that we dont need to have answered these questions with hard numbers
16:06:28 <armadev> 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 <ohmygodel> 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 <nickm> [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 <asn> sure
16:07:50 <syverson> How did we move from having a basic top-down list by next week to having a tech report for July?
16:08:08 <ohmygodel> syverson: im also wondering this
16:08:10 <asn> ok maybe we should see what we can do with this top-down thing till next week
16:08:16 <asn> and see how much there is to think in that space
16:08:21 <asn> maybe we are done in a week.
16:08:47 <syverson> We don't have to be done, just done enough to answer the deferred question on anonstats1.
16:08:55 <asn> ok
16:09:13 <ohmygodel> syverson: agreed
16:09:39 <syverson> The top-down thing can be a work in progress, that could indeed be firmer in the coming months.
16:10:19 <asn> ok
16:10:20 <asn> then
16:10:30 <isabela> is the top-down list of questions in a ticket? (if not, should it be?)
16:10:45 <asn> it is not.
16:10:47 <asn> maybe it should be.
16:10:57 <ohmygodel> so this is the question of where
16:11:12 <asn> We can start a tor-dev thread about it. Or make a ticket.
16:11:15 <ohmygodel> may i humbly suggest etherpad->wiki again
16:11:20 <syverson> I like the suggestion of an etherpad.
16:11:21 <asn> ok
16:11:25 <ohmygodel> that has worked well for us in the past
16:11:26 <asn> etherpad is fine with me.
16:11:43 <syverson> or wiki as ohmygodel says or similar.
16:12:05 <asn> https://etherpad.mozilla.org/psNv5z99Z5
16:12:17 <ohmygodel> thank you asn
16:12:22 <isabela> cool
16:12:32 <asn> ok
16:12:37 <syverson> C'est tout for this week?
16:12:42 <asn> ehm
16:12:57 <ohmygodel> wow we are running long
16:13:01 <asn> yeah
16:13:07 <asn> ok so done with this top-down thing
16:13:12 <asn> and done with the anonstats topic too
16:13:13 <syverson> no we're only 13 minutes in ;>)
16:13:17 <ohmygodel> haha
16:13:25 <asn> what else should we talk about?
16:13:26 <ohmygodel> i did have one small thing to discuss about publishing the tech report
16:13:31 <armadev> 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 <ohmygodel> karsten had some thoughts about this
16:14:13 <asn> ok
16:14:14 <karsten> well, I'd just want us to spend some time on finishing the report, rather than publish as-is.
16:14:22 <asn> ack
16:14:23 <atagar> toralf: Thanks! Fixed: https://gitweb.torproject.org/stem.git/commit/?id=378bfaf
16:14:28 <ohmygodel> karsten: what is there to finish ?
16:14:31 <armadev> 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 <dgoulet> armadev: that all sounds like hs health tool job
16:15:03 <dgoulet> how about we schedule a discussion (or start one on tor-dev) ?
16:15:04 <karsten> ohmygodel: section 4 (?) is still a bunch of ideas thrown together, without much structure.
16:15:09 <asn> dgoulet: well, seems like we found a way to bridge the performance work with the statistics work? :)
16:15:18 <dgoulet> asn: indeed
16:15:37 <dgoulet> asn: much to do in the hs health so if you want to help me on that, be my guess! :)
16:15:45 <syverson> For ohmygodel anything beyond cleaning things up, i.e., anything substantially new will require a new pub release.
16:15:47 <armadev> 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 <asn> dgoulet: ack
16:15:49 <dgoulet> I'm alsmot done with the little-t tor code for this
16:16:13 <karsten> syverson: I think it's mostly cleaning up.
16:16:23 <dgoulet> armadev: yeah
16:16:25 <syverson> karsten: sounds good.
16:16:26 <armadev> asn: is that research question i just raised in-scope for your idea of top-down questions?
16:16:26 <karsten> it's been a while since I looked.
16:16:36 <asn> karsten: i think your section 4 sadness is a general product of our previous bottom-up approach.
16:16:55 <karsten> asn: hmm, maybe.
16:17:01 <asn> at least i know that this is why i didn't like the tech report all this time.
16:17:02 <syverson> No!!! Something else to defer until the top chimes in.
16:17:14 <karsten> well, we could also write a better report based on this one, get it approved, and publish.
16:17:41 <asn> armadev: sure why not
16:17:50 <asn> armadev: noted it to the pad
16:17:58 <syverson> That's OK too, as long as we know which we're doing.
16:18:18 <ohmygodel> karsten: i have to say that am opposed to spending any more time on this
16:18:27 <ohmygodel> i think the structure is perfectly clear and logical
16:18:41 <ohmygodel> i think the information is useful to people trying to understand how we reason about which stats to release and how
16:18:52 <ohmygodel> i think the value of adding to this document is low
16:19:05 <karsten> so, it's not the quality I aim for. I could imagine that you publish without me.
16:19:07 <ohmygodel> and so if we cant agree to publish it nearly as-is, then we should let it die
16:19:43 <asn> 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 <ohmygodel> karsten: perhaps you could provide more detail. maybe you arent asking for that much
16:19:56 <syverson> ohmygodel: are you stating your opinion or speculating about karsten's?
16:20:15 <ohmygodel> syverson: that was my opinion
16:20:34 <karsten> I can provide more detail if I go re-read what we have.
16:20:36 <asn> 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 <karsten> letting it die and reusing parts is also an option.
16:21:09 <armadev> url to this tech report?
16:21:18 <asn> i'm mainly bothered by the "benefits"/"risk" approach which is not very fruitful IMO.
16:21:26 <syverson> Hmm, can we defer this till Karsten re-reads and forms a strong opinion rather than speculating?
16:21:43 <asn> armadev:   https://people.torproject.org/~karsten/volatile/hidden-service-stats-2015-01-10.pdf
16:21:44 <karsten> 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 <karsten> syverson: I can provide more details at next week's meeting.
16:22:20 <dgoulet> karsten: #13192 has the necessary patch, just needs review
16:22:35 <asn> #13192 has been in my TODO list for a while. it's not an easy patch to review.
16:22:58 <ohmygodel> 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 <dgoulet> a Yawning would be very helpful since he basically told me how to fix it
16:23:05 <dgoulet> Yawning: ^ #13192
16:23:13 <syverson> 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 <ohmygodel> *i would be happy to read your
16:23:32 <armadev> 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 <Yawning> meep?
16:24:00 <Yawning> is that the float thing?
16:24:04 <asn> Yawning: ye
16:24:05 <karsten> ohmygodel: let's put this on next week's agenda.
16:24:16 <karsten> not many thoughts to read right now.
16:24:21 <ohmygodel> karsten: ack. thanks!
16:24:51 <ohmygodel> syverson: you know me too well :-)
16:24:53 <Yawning> I'll look over the branch and sign off on it once I'm done eating
16:24:54 <karsten> armadev: agreed about losing relays reporting stats.
16:24:56 <Yawning> :P
16:25:04 <dgoulet> 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 <dgoulet> Yawning: ack, thx
16:25:34 <syverson> Anything else for this week? Gotta run soon.
16:26:02 <asn> 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 <asn> 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 <armadev> hot
16:27:41 <asn> even though I don't see of any powerful attacks that could happen with this stat enabled by deafualt.
16:28:03 <ohmygodel> what could be additionally revealed that isnt already revealed by the volunteers ?
16:28:25 <asn> nothing i can think of
16:28:36 <ohmygodel> 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 <asn> 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 <syverson> 5% 100% what's the difference? ;>)
16:29:05 <ohmygodel> havent we thought about this ?
16:29:12 <asn> yeah we have
16:29:26 <asn> at least I have.
16:29:32 <ohmygodel> ok yes we have
16:29:34 <karsten> not exactly sure what you refer to, asn.
16:29:36 <ohmygodel> 4.2.3 in the tech report
16:29:55 <syverson> Was it simply new to nickm or were there specific questions?
16:29:57 <nickm> 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 <nickm> Compare with
16:30:13 <asn> 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 <ohmygodel> 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 <nickm> "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 <karsten> hmm ok. not sure when I raised that concern. and we also have laplace noise for that.
16:31:12 <syverson> OK that's the offhand statements here, but there was analysis in the report
16:31:15 <nickm> I'm more okay with "all relays report" if it includes something like the anonstats ideas
16:31:29 <ohmygodel> nickm: do you have a specific privacy concern ?
16:33:37 <nickm> ohmygodel: not yet, but I think that stats are guilty until proven innocent
16:33:40 <ohmygodel> 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 <ohmygodel> nickm: acknowledged
16:34:01 <asn> yes, this discussion seems like a + vote for anonstats.
16:34:18 <ohmygodel> in fact, that reason seems enough to me to just decide now to move forward on anonstats
16:34:41 <Yawning> dgoulet: maybe add some unit tests to the routine?
16:34:54 <asn> so I think we should wrap this meeting up.
16:35:06 <Yawning> apart from that it looks good to me
16:35:10 <ohmygodel> if using it will in fact achieve consensus on collecting those two stats (# descs and # HS relay data cells)
16:35:26 <dgoulet> 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 <ohmygodel> ok, well, we can discuss that at the next meeting then
16:35:39 <ohmygodel> asn: i agree that we should wrap up and thanks for watching to time
16:35:40 <Yawning> yah, there's not a lot of cases to cover
16:35:51 <syverson> Hrmm, ohmygodel let asn have the top-down overview by next week before pushing further IMO.
16:36:07 <asn> OK, I think us Tor folks should figure out what we we will be doing till next week.
16:36:31 <Yawning> I suggest test cases added, then come back to me for signoff
16:36:41 <Yawning> 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 <asn> OK, it seems like I will be taking care of this top-down list situation till next week.
16:38:09 <asn> I would also like to take a look at the HS health measurement thing.
16:38:16 <asn> since it seems like the avenue to more statistics.
16:38:23 <dgoulet> asn: oh yeah :)
16:38:26 <asn> or whatever we call these things
16:38:37 <asn> and I also need to write hte monthly report
16:38:55 <asn> 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 <jueok> why tor destroyed vidalia? there is no project page no more
16:39:05 <ohmygodel> asn: ill add to the top-down plan
16:39:12 <armadev> jueok: #tor will be better for you
16:39:38 <Yawning> as to the other stuff in that branch I have no idea what the code does or is supposed to do ;_;
16:40:05 <asn> karsten: I will also look into #15013.
16:40:19 <karsten> asn: thanks!
16:40:30 <armadev> 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 <dgoulet> armadev: I have all the patches needed for the "dump content" (spec and code)
16:41:58 <dgoulet> armadev: currently working on debolting the hs fetch desc. code
16:42:16 <ohmygodel> ok adios amigos
16:42:25 <asn> ok thanks guys
16:42:30 <asn> let's end this mega meeting omg
16:42:32 <asn> #endmeeting