Well, it is a client-side encryption app. If the encryption, public key authentication, etc. is being done well on the client, then the server's only purpose should be routing garbled ciphertext between users and managing things like login, etc.
> (HN is a YC marketing arm, he runs the website and can do whatever he wants, etc, etc).
HN is much more than a marketing arm — it's one of the most central forums for programmer discussions today. And this makes it YC's responsibility to treat it as such.
It's true that we don't have a research paper per se for the multiparty protocol, but we do have a specification document [1] as well as implementations in Objective-C, Java and JavaScript. The specification, as well as the implementations, have received both professional audits (from cryptographers) as well as community audits. The reason we don't have a research paper published is simply because we're working on one right now — a redesign of the multiparty protocol based on OTR. We have cryptographers on board from various Canadian universities and are organizing an internal forum to get them to collaborate on this. We expect publishable results by June 2014.
Regarding OTR, we actually switched to that 16 months ago — it's not exactly like we recently wisened up.
I believe that we've been truly open source, transparent and accountable for our code since day one. There are other projects who are currently similarly open and transparent (I respect TextSecure for this,) but I can't say this is the standard in this field.
We've always solicited and compensated feedback from security enthusiasts, hobbyists and world-famous cryptographers alike. Over the past year, we've had the opportunity to grow into a product that examined what is fundamentally responsibly possible in the browser, and we've even landed ourselves as a primary use-case for the W3C's Web Cryptography working group. We've produced a true, responsible alternative for people who just don't know how to use anything more complicated than Facebook Chat, and we've made it clear that we are not trying to replace PGP or other iron-clad 30-year old solutions. We're trying to help mom and pop users.
We want to do things right. We are truly open source, truly honest, transparent and we take immediate steps for mitigation every time. We will continue to solicit audits and feedback for our more experimental browser client, but also hope to have a more grounded product in our upcoming Objective-C (iPhone) and Java (Android) apps.
Overcoming a bad reputation is extremely more difficult than keeping a good one. We have been less lucky than other projects. The fact that we used experimental platforms and coupled that with overly loud disclosure of all the failures those platforms lended us meant that we couldn't keep face as easily as other projects.
But that said, I can't but resent the continued accusation that after three years at this, myself and all other volunteers (a wide range) working on this haven't matured enough to know what we're doing, and haven't proven that we care very much to do it right. It's very relieving to hear that the community at HN can understand this and see that we have been proceeding responsibly for quite some time now.
> How do you manage to afford to finance the audits and bug bounties?
Public donations from our website and funding from public institutions and NGOs. Currently, our audits are funded by the Open Technology Fund: https://www.opentechfund.org
Generally, our funding tends to be very limited though, so sometimes we have to ask someone to do an audit for cheaper than they usually would, seeing as we're an open source project with no source of revenue.
EDIT: Forgot to mention, we have no funding for bug bounties. I pay all bug bounties out of my own pocket. I don't mind, I feel the money is very well-spent.
Cryptocat's website and the Cryptocat app itself are both fully translated into Catalan, and we maintain a very communicative and open relationship with PuntCAT.
I like to think that the Cryptocat team and myself have matured beyond the point where we consider security disclosures to be punishment, but rather something to be expected when handling a project that wields experimental technology. We're trying to be adults by adopting principles of full disclosure, mitigation, transparency, public involvement, and making sure our process is tweaked to prevent the repetition of past mistakes.
* Cryptocat: The original client. It's a signed browser extension that you download and install in your browser. It offers OTR implemented in JavaScript in a friendly chat interface. We take every precaution to make JavaScript more secure, such as using a signed browser extension to prevent code delivery MITM, using native cryptographically secure random number generation, and so on. More info on our JavaScript approach at my personal blog: http://log.nadim.cc/?p=33
* Cryptocat for iPhone: No JavaScript here! This is an app written in Cocoa Touch/Objective-C that implements OTR and our multiparty group chat protocol. It's really quite a simple app compared to what we had to do to put encrypted chat in the browser. It's new and needs review! Find bugs! Help a cool open source project! We'll send you rewards!
* Cryptocat for Android: No JavaScript here! This is an app written in Java that implements OTR and our multiparty group chat protocol. It's really quite a simple app compared to what we had to do to put encrypted chat in the browser. It's new and needs review! Find bugs! Help a cool open source project! We'll send you rewards!
All three clients are made to be 100% inter-operable.
Isn't that how tech-centered controversies work? Especially in cryptography.