<div>I've been waiting to reply to this until I can give it an hour to get my thoughts down.  Hopefully it's not too late.  This is a very important question: where should we spend our time, and our effort?  Because I know you Moritz, I'm going to stray heavily into the Liberation Tech side of things, as well as crypto.</div>

<div><br></div><div>Of course my first thought it towards auditing, since it's my day job.  I've audited many open & closed source projects that were directly cryptographic or built on top of cryptography, and found critical flaws.  This is a no-brainer.  And it's valuable. But is it the *most valuable thing*?  For some apps, yes, for most apps, probably not.</div>

<div><br></div><div>There are a host of hard problems we don't have good solutions to.</div><div><br></div><div>For example, so many cryptographic projects are focused on content confidentiality: PGP Email, OTR, IPSEC, SSL, so on and so forth.  So _few_ are focused on sender and receiver anonymity.  The techniques to achieve that: onion routing, mixing, anonymous(?) broadcasts, shared mailboxes, PIR, are so under documented in accessible forms that they're never considered in new censorship circumvention or anonymity tools.  Research into these areas, and bringing the content into more accessible forms, with blog posts, graphics, architecture discussions and designs would be awesome.</div>

<div><br></div><div>Similarly - so many encryption applications are widely distrusted because they are centrally managed.  Psiphon, Wickr, Silent Circle, Cryptocat, RedPhone, so on and so forth.  Research and explanations into how to deploy a centrally managed but untrusted network would be invaluable.  A great example is Tor's Directory Server design.  Frankly I'm only familiar enough with it to know its strengths, not its weaknesses - but accessible explanations into how it works, and how you can design similar things, would be amazing.  As a very practical example: Mixminion is in desperate need of a directory service similar to Tor's.  NickM said today "There isnt' currently actually a design for the distributed directory thing you'd want. I wrote a draft long ago, but I was even less good at this stuff back then."  Nick's being quite humble - the skeleton of one is there, and the learning process of fleshing it out and developing it would be invaluable for the community.</div>

<div><br></div><div>Another pervasive problem is that virtually all of our tools are detectable on the wire by a network admin, and classifiable.  I've thought about this, and broken censorship into a few buckets in my head:</div>

<div> - Source Censorship: You are censored. You're not allowed to go online.  (Well crap.)</div><div> - Destination Censorship: No one can talk to this IP, or resolve this domain name</div><div> - Content Censorship: TCP reset packets that contain the words 'Falun Gong' OR have a specific byte sequence (like the old Tor SSL handshake)</div>

<div> - Pattern Censorship: If someone has an SSH tunnel open, and they're sending significantly more data than they're receiving, they must be transferring an outgoing file, and kill that connection, but not other SSH connections.  (And similar ideas like "Well this SSL stream sure doesn't *seem* like HTTP...")</div>

<div>Nearly all of our tools are, or can be, caught with Pattern Censorship.  And it's very important to recognise you can also detect without censoring.  "Who in my company is sending PGP emails from work?" "Who in the US is using Tor?".  It would be worthwhile to raise the bar for tools (i.e. every tool expect Tor's obfsproxies) so that adversaries have to move on to Pattern Censorship.  It will be possible of course - it's an arms race.  But when we get to pattern censorship, we'll make it harder for them.</div>

<div><br></div><div><br></div><div><br></div><div>There are other ideas.  </div><div><br></div><div>Of course there's that whole 'almost none of our tools are usable' problem.</div><div><br></div><div>And the 'oh lawd, libpurple and ZRTPCPP are horrible' issue.  </div>

<div><br></div><div>You could fund someone to black box reverse engineer closed apps like Wickr, Silent Circle, WhatsApp, GoAgent, iMessage, etc - and explain their architecture.  </div><div><br></div><div>Or fund someone to document that which is not-too-documented.  I recently read "From a Trickle to a Flood" that is a fantastic summary of Mix Network pooling algorithms.  Something similar to that for undocumented things.  Something I've been struggling with for a bit is Type I remailer instructions, and why they were chosen.</div>

<div><br></div><div>I'm sure most people on this list have half completed drafts of serious proposals that could really improve things - but need someone to finish the draft, publish, and potentially write code.  I believe in Academia the term for such people is 'Grad Students'.  Have people submit their half-written proposals and fund grad students for them.  I know I'd submit ;)</div>

<div><br></div><div><br></div><div><br></div><div>In conclusion - I would recommend that besides funding individual projects, you also consider some of the issues that we as a community are lacking either solid architectures of; or accessible explanations of how to integrate those architectures into projects.</div>

<div><br></div><div>-tom</div>