[graue]

Cryptocat was and is open source too:

https://github.com/cryptocat/cryptocat

That doesn't solve the problem. No one is going to manually view source and compare it every time they use the damn thing.

> To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.

At rest. Yes, at rest it's fine, like I said, but if someone logs in while the server is compromised, it would be trivial to decrypt anything they post or access during that session. Same as Lavabit.

> We'll be releasing [..] a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.

So it'll download two copies of the code, one from your servers and one from GitHub, and check that they match? Doesn't seem to me that that buys you much. And unless it's mandatory, you'll be leaving the users that don't install the extension unprotected.

See here for a long list of other reasons in-browser crypto is problematic: http://www.matasano.com/articles/javascript-cryptography/

[mediocregopher]

When you create an account with cryptic.io, a private key is generated in browser and encrypted with the hash of your password. This encrypted private key is what we keep server-side. All files you upload, and all of your user-data, is encrypted using that private key. In short, all encrypting/decrypting of ANY sort happens inside your browser. So someone logging onto the server and viewing data as it is uploaded is still seeing encrypted data. Short of compromising a user's computer there is no way for them to see it. Our encryption scheme is nothing like the scheme that lavabit used.

The extension won't be able to mitigate an attack, but it will be able to alert you to one, which for someone who had the initiative to install it (which we will be heavily encouraging users to do) would be enough to inform them that something is amiss. And if something is amiss they can host the front-end themselves and use a local copy of the html/js/css so they can be sure they're getting a good copy of the site (something we will also be making easy to do).

[teod]

I have thought about a similar service but was dissuaded by various sources warning against the idea of using javascript with cryptography, e.g. http://www.matasano.com/articles/javascript-cryptography/. That's not to say a reasonable solution cannot be found, but there are a good number of issues that need to be addressed. The one that seems crippling to me is that the strength of javascript crypto libraries is questionable at best - nevermind the various other javscript attack vectors. A browser plugin could address some issues, but then that limits users to browsers with the plugin installed. Might as well have a native application where the quality of the cryptographic algorithms are more thoroughly tested at that point. Still, I like the idea and wish you the best of luck.

[read]

What happens if a user changes client machines?

You seem to suggest storing their hashed password in the browser, but if they change machines they won't have that hashed password around. How will you go from plaintext password to hashed password without having the salt used with PBKDF2?

You say user passwords are never sent over the wire (not even the hash)[1], but then say users have an object containing their hashed password (is the documentation here out of date?)

[1] - https://github.com/cryptic-io/web