16:03:55 <asn> #startmeeting
16:03:55 <MeetBot> Meeting started Tue Dec  9 16:03:55 2014 UTC.  The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:55 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:04:02 <asn> ohmygodel: ack.
16:04:23 <ohmygodel> ok that’s it haha
16:04:26 <asn> great
16:04:33 <asn> so let's start with what we've been doing past week
16:04:38 <asn> and we move to discussion in a bit.
16:04:44 <asn> so personally, I've been doing non-SponsorR stuff
16:04:47 <asn> but on the SponsorR front
16:04:55 <asn> I've been running a relay that is collecting stats
16:04:57 <asn> for the past 5-6 days
16:05:03 <asn> so far the stats look like this:
16:05:19 <asn> [warn] Original rp_relay_cells_seen: 96291. Obfuscated: 90112 Original hs_stats->hs_seen_as_hsdir: 54. Obfuscated: 56
16:05:22 <asn> [warn] Original rp_relay_cells_seen: 1278. Obfuscated: 1024 Original hs_stats->hs_seen_as_hsdir: 83. Obfuscated: 88
16:05:25 <asn> [warn] Original rp_relay_cells_seen: 18068. Obfuscated: 19456 Original hs_stats->hs_seen_as_hsdir: 108. Obfuscated: 112
16:05:28 <asn> [warn] Original rp_relay_cells_seen: 22504. Obfuscated: 8192 Original hs_stats->hs_seen_as_hsdir: 119. Obfuscated: 136
16:05:31 <asn> ponder on these for a bit
16:05:36 <asn> i also posted a new version of proposal 238 on tor-dev
16:05:44 <asn> that details how exactly we are currently doing obfuscation
16:05:54 <ohmygodel> yeah i just sent a reply
16:05:55 <asn> and I just noticed that ohmygodel replied with a different way of doing this.
16:06:07 <ohmygodel> yeah i think you should flip the order of noise and binning
16:06:18 <asn> ohmygodel: btw, is "binning" an established term with a name?
16:06:23 <asn> because i'm calling it round-up obfuscation.
16:06:24 <asn> anyway
16:06:38 <asn> i also looked at the tech report a bit. i have a small patch, but I could do more there so I haven't published it.
16:06:39 <ohmygodel> yes: <https://en.wikipedia.org/wiki/Data_binning>
16:06:41 <asn> and that's that from me.
16:06:43 <asn> ohmygodel: cheers
16:06:48 <asn> who wants next?
16:06:57 * karsten can go next
16:06:59 <asn> karsten: go!
16:07:10 <karsten> I picked up asn's branch that implements said proposal 238
16:07:21 <karsten> and added obfuscation as we discussed it last week.
16:07:34 <karsten> I also tested it in a local chutney network.
16:07:51 <karsten> and I looked at asn's revised proposal. like it.
16:07:54 <karsten> that's all.
16:08:03 <asn> great
16:08:06 <asn> great work with the coding btw
16:08:10 * dgoulet can go next
16:08:14 <karsten> asn: :)
16:08:15 <asn> dgoulet: go!!
16:08:50 <dgoulet> also pretty quick, last week was mostly for me to finalize part of the measurement framework I've been working on, my goal is to have the report and doc. this week
16:09:04 <dgoulet> review karsten/asn code also
16:09:14 <ohmygodel> dgoulet is this for measuring hs performance ?
16:09:16 <dgoulet> read the proposal which is pretty fine by me
16:09:17 <syverson> I talked to Aaron (ohmygodel) about obfuscation and how it is both more useful and more secure to do this on the global aggregate than locally
16:09:20 <dgoulet> ohmygodel: yes
16:09:25 <ohmygodel> ok thx
16:09:39 <atagar> good morning, world
16:09:44 <dgoulet> ohmygodel: private network, we still have to setup it on Shadow (with rob) but in the making
16:09:58 <asn> dgoulet: great.
16:10:05 <dgoulet> done
16:10:08 <asn> who next?
16:10:16 <asn> syverson: ack!
16:10:22 <ohmygodel> syverson you done ?
16:10:48 <syverson> What? Sorry.
16:10:53 <asn> syverson: you wanna do a status report?
16:11:01 <asn> apart from 16:09 < syverson> I talked to Aaron (ohmygodel) about obfuscation and how it is both more useful and more secure to do this on the global aggregate than locally
16:11:11 <asn> or that summarizes your activity sufficiently?
16:11:24 <syverson> Oh. Ermm thinking.
16:11:47 <asn> actually what does "how it is both more useful and more secure to do this on the global aggregate than locally" mean?
16:12:04 <asn> doing obfuscation on the global value instead of individually in each meter?
16:12:13 <syverson> Read through the tech report and made a bunch of hand notes. Wasn't sure about editing it.
16:12:43 <karsten> that would be very interesting feedback, syverson.
16:13:23 <karsten> assuming you mean the tech report where we outline what stats we might gather about hidden services in the future.
16:13:33 <karsten> and what we should rather not gather.
16:14:06 <asn> ok great
16:14:07 <syverson> Well if you are adding noise per HSDir, then the cumulative effect can be bad.
16:14:23 <asn> yes
16:14:27 <asn> too much noise, you mean?
16:14:54 <ohmygodel> well more than is necessary
16:15:02 <asn> ye
16:15:17 <ohmygodel> because all we currently want is a single number
16:15:27 <syverson> Yes. That report. Nothing deep so far. One thing I was doing was changing hidden service to .onion site everywhere as per some other conversations.
16:15:30 <asn> ok ohmygodel wanna finish with status report?
16:15:35 <ohmygodel> reporting per-relay is only because it is the easiest to do
16:15:39 <asn> or you are fine with moving to discussion directly?
16:15:53 <ohmygodel> yes ill go
16:16:11 <ohmygodel> ive been thinking about privacy threats for the proposed stats
16:16:14 * aagbsn waits turn
16:16:19 <asn> aagbsn: ack!
16:16:24 <ohmygodel> one minor issue
16:16:41 <ohmygodel> is that currently the security stuff only exists in the proposal
16:16:58 <asn> there is this "risk" session in every stat in the tech report
16:17:02 <ohmygodel> but the tech report is the place where were collecting discussio of all stats
16:17:06 <asn> yes
16:17:07 <asn> i agree
16:17:20 <asn> i also get a weird feeling reading the tech report
16:17:24 <ohmygodel> so, should that be ported back from the proposal ?
16:17:33 <asn> i'm not sure if the "details / benefits / risks" model is the best model.
16:17:41 <karsten> not at all, asn.
16:17:48 <asn> but i can't think of a much better model either.
16:17:50 <karsten> it was just useful for collecting ideas.
16:17:53 <asn> karsten: yes
16:18:03 <karsten> the tech report needs quite some love.
16:18:05 <asn> ohmygodel: yes, ideally all those security problems from the proposal should have a nice place in the tech report.
16:18:17 <asn> the tech report should ideally have a section on obfuscation too...
16:18:44 <karsten> note that the proposal is almost (?) ready for publication, whereas the tech report is for january 15.
16:18:47 <karsten> or 12.
16:18:48 <ohmygodel> ok that answers that problem
16:18:48 <asn> karsten: yes
16:18:59 <ohmygodel> so my approach is to consider
16:19:10 <asn> tbh I can see the tech report dragging past jan15. but we should definitely have a decent first version ready by then.
16:19:14 <ohmygodel> 1. what things we want to make sure to keep private
16:19:25 <karsten> asn: makes sense.
16:19:37 <asn> karsten: :)
16:19:47 <ohmygodel> 2. what background knowledge the adversary could plausibly have
16:20:23 <ohmygodel> so i guess that follows the “risks” approach, but i think it a good way to think about it
16:20:23 <asn> (and we are now moving towards the discussion phase of this meeting btw)
16:20:38 <asn> (we should let aagbsn say his report too)
16:20:40 <asn> ohmygodel: yes I agree
16:20:47 <ohmygodel> ok sure that ends my status update
16:20:54 <asn> ohmygodel: ack thanks!
16:20:56 <asn> aagbsn: next?
16:21:21 <aagbsn> ok
16:21:27 <aagbsn> dropping by per roger's recommendation and attempting to catch up / see where I can be useful here. dgoulet sent me a few links (SponsorR, SponsorRtasklist. are these being assigned to people as they pick them/are there any tasks no one else wants to do?
16:21:41 <asn> hm
16:21:45 <asn> that's a good question.
16:21:48 <asn> we should think about this.
16:21:51 <asn> that is, where you can fit.
16:22:19 <asn> i don't have a good answer atm, because my view is quite narrow towards the first deadline on jan 15th.
16:22:22 <aagbsn> I got rogers email earlier today and haven't had a lot of time to look at things yet
16:22:30 <asn> and till then, we have a good idea on who does what.
16:22:41 <asn> but I think we can definitely find tasks for people.
16:22:49 <ohmygodel> is anybody working on figuring out how much our stats are polluted by crawlers ?
16:22:55 <asn> ohmygodel: no.
16:22:58 <aagbsn> probably I can look at tor controller related code
16:22:59 <asn> ohmygodel: no one is working on this.
16:23:25 <ohmygodel> ok, theres an idea
16:23:32 <ohmygodel> not sure if thats the best use of aagbsn’s time
16:23:58 <aagbsn> perhaps there are thinsgs most directly applicable to jan15 deadline?
16:24:30 <aagbsn> is there a set of things that are supposed to be done by then?
16:24:36 <asn> yes
16:24:46 <asn> *** learn number of HSes / how much HS traffic
16:24:47 <asn> *** privnet benchmarking // interesting observations that lead to surprising results
16:24:49 <asn> *** have a list of tasks/projects ready (read the thread)
16:24:50 <asn> this is the rough list.
16:24:52 <asn> *** perfromance baseline
16:24:54 <syverson> I didn't see it as safe statistics per se, but I have been describing to ohmygodel (and a little to Roger) setting up a reporting site and also "honey" detection for when a cralw is taking place.
16:25:08 <asn> sysrqb: interesting
16:25:26 <asn> syverson: interesting
16:25:30 <aagbsn> syverson: donncha of oniontip was talking about a honey system
16:25:40 <aagbsn> might want to loop him in here too
16:25:42 <syverson> This is sort of like exonerator (but only sort of)
16:26:08 <asn> aagbsn: so, the above 4 bullet points are what we need to deliver by jan15th supposeldy.
16:26:15 <asn> aagbsn: the first one is proposal238 that I just sent to [tor-dev]
16:26:31 <asn> aagbsn: the second one is the work that dgoulet is doing with chutney
16:26:39 <asn> aagbsn: the third one is https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorRtasklist
16:26:46 <asn> aagbsn: the fourth one is also related to what dgoulet has been doing
16:26:56 <syverson> Mostly I just wanted to detect when crawls were taking place, but it could also be used to distinguish "benign" crawls from scanning for attack surfaces, etc.
16:27:12 <aagbsn> wait, bullet 3 is all the tasks on that list?
16:27:23 <karsten> make the list, not do the things.
16:27:30 <aagbsn> oh, ok :)
16:27:40 <asn> syverson: isn't this a bit of an arms race though?
16:28:01 <asn> syverson: that is, we detect crawling. they change software to crawl in a different way . we detect new crawling. they change software etc.
16:28:26 <asn> syverson: but I like the idea.
16:28:28 <dgoulet> one thing for Jan 15th that could be good is to present performance improvement and it's possible to do on the host side like #13739 (I think there are other ticket that slow path have been identified)
16:28:54 <syverson> I'm mostly not concerned with adversarial crawling, though we can consider it. I'm mostly concerned with recognizing benign crawls to see how it affects statistics.
16:28:56 <ohmygodel> asn: what’s the arms race? its passive observation
16:29:25 <asn> what is adversarial crawling and what is bening crawling? :)
16:29:38 <asn> they seem kind of the same to me tbh.
16:29:53 <asn> ohmygodel: well, the arms race is that of detecting crawling as an action.
16:29:58 <asn> differentiating between normal client and crawler.
16:30:06 <asn> from the PoV of a website operator, I guess.
16:30:10 <ohmygodel> what is the incentive to change your crawling behavior ?
16:30:23 <asn> to not get detected by the crawling detectors
16:30:27 <asn> if you even care  so.
16:30:37 <syverson> Sorry. Somebody trying to see the HSes that are out there as opposed to scanning HSes to see which are vunerable to attacks.
16:30:41 <karsten> not trying to kill the discussion, because it's a good thing to do, imo. but this is something for post-jan15, right?
16:30:50 <ohmygodel> ok, but the purpose of crawling detectors is just to adjust our statistical inferences
16:30:53 <asn> karsten: yes, I think so.
16:31:11 <asn> karsten: i think the above 4 bullet points I posted is what we are doing for jan15. everything else is discussion for now :)
16:31:17 <karsten> ok.
16:31:19 <asn> ohmygodel: ah, I see.
16:31:38 <ohmygodel> asn: i think that adjusting for crawling behavior is plausibly doable and interesting for jan 15
16:31:41 <asn> i was imagining that the purpose of crawling detectors would be to *stop* the crawling.
16:31:45 <ohmygodel> if there is someone who has time
16:31:55 <syverson> I'm going to start on it soon, but I may be able to mostly coordinate with SRI folk and not involve others who are too busy with other things.
16:31:59 <ohmygodel> i was hoping the SRI people might do it, but if Tor has a person, great
16:32:10 <asn> maybe aagbsn could be the person!
16:32:19 <asn> but can you explain a bit more in depth what you mean?
16:32:46 <ohmygodel> figure out how much of the RP activity we see is due to crawler fetches
16:32:52 <asn> like, we run some HSes, we check the amount of crawling that happens, and then we put this knowledge into the statistics to weed out crawling traffic from real traffic?
16:33:08 <aagbsn> a design I overheard was to run some HS that are never listed publicly
16:33:15 <syverson> At least two things. At simplest you just have a site where people can announce they are doing (or did if they don't want to announce in reatlime) a crawl.
16:33:36 <aagbsn> to look for crawling that is done by running hsdir and snooping
16:33:52 <ohmygodel> aagbsn: yes! watching the wattchers
16:34:05 <syverson> Second, set up a bunch of HSes that don't have much other purpose and watch the pattern of accesses to them. Announce their results on the same site.
16:34:30 <karsten> without telling which sites these are.
16:34:42 <DonnchaC> I'm currently working on detecting HSDir's who are crawling the DHT
16:35:26 <DonnchaC> Current plan is to set up some relays, then to run some HS's which only publish their descriptors to my relays.
16:35:30 <asn> syverson: and what's the end goal? to learn how many entities are crawlin?
16:35:40 <asn> syverson: or to learn how *much* they are crawling?
16:35:44 <syverson> There are separate possibilities for what you want to detect. If the "honey" HSes are not publicly announced anywhere, that might indicate misuse by an HSDir.
16:36:17 <syverson> But for the publicly announced ones, it's just showing benign (sorry) crawling.
16:36:34 <DonnchaC> I'm then going to publish a descriptor for a unique HS to each HSDir (modifying the descriptor_id and resigning).
16:36:59 <asn> DonnchaC: that's nice.
16:37:07 <syverson> asn: my thought is that crawling the web does not disrupt the web much, but crawling a tiny thing like .onion space really displaces the statistics.
16:37:21 <DonnchaC> By monitoring the resulting descriptor fetches and connections, it should be possible to figure out the malicious HSDir's, potentially blacklisting them
16:37:21 <asn> DonnchaC: i think the pubkey also needs to match because HSDirs will check whether they are in the correct slice before serving a desc
16:38:09 <asn> DonnchaC: see hid_serv_responsible_for_desc_id()
16:38:11 <dgoulet> DonnchaC: yeah what asn is saying is a problem here, the HSDir won't accept to store de descriptor if the pubkey is not in the range of it
16:38:29 <dgoulet> of the HS*
16:38:38 <asn> syverson: yes, that might be true.
16:38:43 <karsten> DonnchaC: what asn and dgoulet say. but when you create a new pubkey, be sure to reuse introduction points.
16:38:50 <DonnchaC> dgoulet: I'll recheck, I thought it checked the descriptor id but not the public key
16:38:55 <syverson> DonnchaC: that was something I was considering, but I mostly was focused on the statistical impact of crawling first.
16:39:05 <asn> syverson: but do you think we  will be able to learn "So crawling is X% of the HS traffic" from this experiment?
16:39:27 <asn> syverson: we might be able to learn "there are N different crawlers crawling the Tor network"
16:39:45 <asn> syverson: or even "crawler Y is _this_ fast, and crawler Z is _that_ fast"
16:39:56 <asn> syverson: but not sure how to get the crawler's influence on the statistics.
16:40:08 <asn> but it seems like an interesting project.
16:40:17 <asn> shedding more light to the crawling activity seems worthwhile.
16:40:18 <dgoulet> DonnchaC: not on the HSDir part, the client had that issue (maybe #13214 is what you are talking about)
16:40:23 <syverson> Not sure. At the least you should be able to say, here are the statistics during a period when we knew crawling (or n crawls) were taking place, and here's the stats when no crawls were detected.
16:40:52 <asn> hmmmm
16:40:59 <asn> plausible
16:41:20 <asn> although "no crawls were detected" might actually be "no crawlers were stupid enough to hit our weird unknown HS"
16:41:35 <asn> but the smart crawlers will still be crawling the public HSes that are not run by us.
16:42:05 <ohmygodel> yeah and there are definitely crawlers focused on only certain specific HSes
16:42:25 <syverson> Even if we just differentiated when SRI's darkcrawler and ahmia were crawling and when they weren't would be useful.
16:42:25 <aagbsn> might be able to insert links to a honion (honey-onion) on other public hs in a way that humans wouldn't click them
16:42:25 <ohmygodel> e.g. Grams
16:43:07 <syverson> Similarly if somebody else we don't know about is doing research crawling we can find that.
16:43:44 <asn> aagbsn: do you find this an interesting problem to work on
16:43:46 <asn> ?
16:43:48 <asn> it's fun.
16:43:53 <DonnchaC> dgoulet: I don't think the HSDir recalulates the descriptor id when it receives a descriptor, it just uses the one provided in the descriptor and checks if it is responsible for the provided descriptor_id
16:44:06 <dgoulet> DonnchaC: yup exactly
16:44:39 <asn> we can also setup HSes of different publicity.
16:44:42 <syverson> This is intiial stuff, to perhaps have something to say for January. The adverarial aspects can be addressed but if we should at least try to know how the non-adversarial activities affect things.
16:44:49 <asn> one of them can be completely private, the other can be on ahmia, the other can be wherever, etc.
16:45:16 <aagbsn> asn: could be, depends what we decide to do :)
16:45:39 <asn> i think differentiating adversarial (finding vulns) from bening crawling (search enginers or whatever this might be) will be exteremely hard
16:45:44 <asn> it's bascially the IDS game.
16:46:14 <asn> aagbsn: well, this seems like something useful and tractable
16:46:18 <aagbsn> might want to know if 2 requests are from the same crawler
16:46:26 <aagbsn> e.g. fuzzing, not walking
16:46:36 <syverson> The goal should probably not be to win the arms race but to get the low hanging fruit and then quit the race.
16:46:44 <DonnchaC> I'm going to keep working on detecting adversarial HSDir's (logging DHT requests) anyways. I'll let you know what kind of results I get.
16:46:46 <asn> syverson: heh
16:46:49 <aagbsn> also look for scanners that try to connect to ports other than 80, etc
16:46:54 <asn> DonnchaC: yes, seems worthwhile.
16:46:57 <asn> DonnchaC: keep us in the loop.
16:47:42 <aagbsn> not sure how to make tor listen to all ports, for example
16:47:47 <DonnchaC> I'd imagine it should be possible to identify some malicious relays, and corrolate what relays are possibly run by the same people/groups depending on the fingerprint of the crawl
16:47:52 <dgoulet> aagbsn: a patch will go in soon for that but yeah that could be a very intersting stat also, if HS get portscan: https://trac.torproject.org/projects/tor/ticket/13667
16:48:09 <asn> OK, so let's move to the next discussion topic?
16:48:21 <DonnchaC> aagbsn: Can try to log the rendevous request too, rather than just connections to port 80
16:48:28 <ohmygodel> if so id like to discuss more complicated protocols for stats collection
16:48:32 <ohmygodel> (i gtg in 12min)
16:48:45 <asn> ohmygodel: ok let's talk about this!
16:49:00 <asn> ohmygodel: you mean some way for all relays to communicate with each other and exchange stats
16:49:00 <ohmygodel> so it would be really great if we could do something like privex
16:49:06 <asn> right
16:49:10 <karsten> DonnchaC: 4583     log_warn(LD_REND, "Parsed descriptor ID does not match "$
16:49:10 <karsten> 4584              "computed descriptor ID.");$
16:49:10 <ohmygodel> something like that yeah
16:49:24 <karsten> DonnchaC: look for that in src/or/routerparse.c
16:49:33 <ohmygodel> is this something work shooting for in the next few months ?
16:49:37 <asn> my first thoughts are "big project. not completely unreasoanble."
16:49:44 <DonnchaC> karsten: Thanks, I'll check it out
16:49:47 <asn> ohmygodel: unclear.
16:49:49 <ohmygodel> and what are the big problems to solve
16:49:49 <asn> ohmygodel: my plan was
16:50:02 <asn> ohmygodel: to let roger and dgoulet go to this meeting on jan15
16:50:15 <asn> and use the tasklist https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorRtasklist
16:50:19 <asn> + any other tasks we add in there
16:50:30 <asn> and come out of the meeting with some tasks that we and the funder wants us to do.
16:50:51 <asn> i have not read the privex paper
16:50:59 <asn> so i cannot really evaluate how much time it would take
16:51:11 <dgoulet> 224 would be nice also
16:51:13 <ohmygodel> i believe that karsten has
16:51:15 <asn> but it seems like a multi-months project.
16:51:32 <karsten> ohmygodel: I can't say how much effort it would be.
16:51:50 <karsten> ohmygodel: as a reference, implementing this simple laplace thing with tests and all that took us 1, maybe 2 days.
16:51:50 <asn> ohmygodel: i will definitely add privex-like things to the tasklist though
16:52:11 <ohmygodel> ok that sounds good and we can discuss it at the jan mtg then
16:52:16 <karsten> ohmygodel: I think we'll need to write a lot of code for privex that seems simple from a design perspective, but that is quite hard to write.
16:52:26 <ohmygodel> im not advocating privex per se
16:52:30 <asn> ohmygodel: yes
16:52:42 <asn> karsten: it might not be uber hard, since relays talk to each other with cells already.
16:52:45 <ohmygodel> im suggesting a centralized statistics aggregation method
16:52:49 <asn> so we would have to add new cell types that carry statistics
16:52:56 <karsten> asn: I'm open to discussing it.
16:53:01 <asn> yee...
16:53:04 <ohmygodel> one that could be just for a few HS stats initially
16:53:16 <ohmygodel> although in the long term, its a good model for very many Tor metrics
16:53:21 <asn> yes maybe
16:53:24 <karsten> yup.
16:53:36 <ohmygodel> i dont see a new cell type being needed
16:53:40 <ohmygodel> this could be a completely separate module
16:53:44 <ohmygodel> completely separate code
16:54:10 <ohmygodel> i see two issues
16:54:30 <ohmygodel> 1. implementation using some crytographic tools not previously used
16:54:48 <ohmygodel> e.g. some homomorphic encryption scheme
16:54:55 <asn> oh god
16:55:36 <ohmygodel> 2. setting up infrastructure to support the collection (e.g. something like directory auths but for stats)
16:55:36 <syverson> asn: it's just exempli gratia
16:55:54 <asn> ye sure
16:56:07 <asn> it just seems like a big project just for the sake of stats :)
16:56:11 <ohmygodel> asn: yes if there simply doesnt exist a reliable implementation of the needed cryptosystem, then were SOL
16:56:58 <asn> anyway, I guess we need to read the privex thing first.
16:57:03 <ohmygodel> Tor gets lots of money for stats
16:57:07 <ohmygodel> stats are really useful and interesting
16:57:14 <asn> i don't think I should comment too much without reading the paper first.
16:57:32 * asn shrugs
16:57:39 <ohmygodel> ok so thx for putting it on the task list
16:57:40 <asn> i would prefer to spend that money on performance
16:57:48 <asn> but anyway, I don't mind.
16:57:52 <ohmygodel> yeah and i would prefer to spend that money on privacy
16:57:53 <asn> we should think about this for sure.
16:57:55 <syverson> No idea, but we could try to mine what's come out of the DARPA PROCEED program.
16:58:04 <asn> ohmygodel: :)
16:58:25 <ohmygodel> #fundingissues
16:58:42 <syverson> ponies
16:58:46 <asn> so this discussion topic is done too.
16:58:49 <asn> what's next?
16:59:29 <asn> ohmygodel: i need to think more about your obfuscation reply
16:59:29 <asn> btw
16:59:41 <asn> ohmygodel: that is, inverting the order of that function composition.
16:59:45 <asn> it probably makes sense, but I don't get it yet.
16:59:52 <ohmygodel> ok
16:59:59 <ohmygodel> and now its noon
17:00:07 <ohmygodel> peace friends
17:00:15 <dgoulet> ohmygodel: o/
17:00:16 <asn> ok thx
17:00:34 <asn> syverson: btw, would you be interested in doing a blog post about mixed-latency anonymity? :)
17:01:20 <asn> https://trac.torproject.org/projects/tor/ticket/13192#comment:21 hah
17:01:41 <dgoulet> yeah I laught
17:02:03 <asn> funny cause it's true
17:02:07 <asn> but anyway
17:02:11 <syverson> ermm I might participate, but if it's something that needs a publication release I should let someone else be the author.
17:02:23 <asn> syverson: no, not really.
17:02:33 <asn> syverson: there is just lots of interest in doing higher-latency anonymity lately
17:02:35 <admin-pc> hey
17:02:47 <asn> syverson: and most of us don't really know how to start thinking about htis problem
17:02:57 <admin-pc> is there a community board for the tor project? I got this idea that will improve anonymity for all outproxy users.
17:03:00 <asn> syverson: and I was imagining that you would have some ideas.
17:03:27 <asn> syverson: anyway, think about it, and if you are interested in writing something send me an email :)
17:03:33 <asn> syverson: blog post, tor-dev post, whatever all is fine.
17:03:40 <asn> it doesn't even need to be big.
17:04:17 <syverson> ideas != time unfortunately. I'm trying to get myself up to speed on the stats and HS stuff that I haven't been looking at enough.
17:04:40 <asn> syverson: ye :)
17:04:43 <asn> syverson: no problem :)
17:05:00 <aagbsn> is there anyone looking at multi-path circuits?
17:05:12 <aagbsn> e.g. so connections can persist a relay failure
17:05:33 <syverson> I would like to look at mixed-latency stuff and mixing. The important thing is not to get too distracted by the interesting cool things when there's work to do. ;)
17:06:00 <asn> syverson: you mean not get distracted by stats when there is actual anonymity work to be done, right? :)
17:06:03 <asn> syverson: j/k
17:06:06 <aagbsn> lol :)
17:06:33 <asn> aagbsn: nope. mainly mikeperry has been looking into this.
17:06:41 <admin-pc> @asn The idea is putting all out-proxy behind a hidden service so out-proxy IP are not public anymore. It would make Tor very hard to block, add plausible deniability to out-proxy user.
17:06:43 <syverson> aagbsn: actually that is the funding we had to work on onion routing when we designed Tor.
17:07:22 <asn> admin-pc: outproxy is I2P terminology right?
17:07:28 <asn> admin-pc: it's the same as exit nodes in Tor? or not?
17:07:34 <admin-pc> @asn no
17:07:48 <admin-pc> out-proxy = socks-5 proxy server behind hidden service
17:08:00 <admin-pc> in tor we dont have it
17:08:04 <admin-pc> we simply have exit nodes
17:08:14 <admin-pc> and they know way too much :(
17:09:18 <asn> %endmeeting
17:09:20 <asn> #endmeeting