[graue]

> we are creating a client-side, in-browser encryption system where a user can upload their already encrypted content to our storage system and be 100% confident that their data can never be decrypted by anyone but them.

This concept may sound clever at first but gives you as the user no additional confidence compared to encrypting data on the server side upon arrival. Either way, you're trusting the host.

The threat model for server-side encryption is essentially:

1) the host has an unethical employee who wants to read your content.

2) the host's servers are insecure and get compromised.

3) someone successfully MITMs your connection to the host (possibly due to the SSL problems being discussed here).

4) the government compels the host to provide your data (i.e. what happened with Lavabit).

The threat model for browser-based client-side encryption is the same! In any of these cases, the attacker (or the host, in case of #1 or #4) simply sends JavaScript encryption code to your browser with a backdoor in it.

Cryptocat originally worked the same way: all chats were encrypted on the client side, but with JS code sent from the server, in which a backdoor could be inserted at any time. After much criticism, this is why Cryptocat is now a browser add-on, with discrete releases made available from a central source (Chrome Store/Mozilla addons site), which can be audited.

[mediocregopher]

One of cryptic's features is that the front-end is completely open-source. You can see the source for the current prototype here:

https://github.com/cryptic-io/web

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

And since the whole frontend is open-source and is only html/js/css, you can host it on your own box if necessary.

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.

[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/

[read]

The browser extension is the missing link. That's what makes it impossible for malicious code in a frontend's source code to go unnoticed.

I wish you had an example of a custom application that uses your storage, so people can see how easy/hard it is to use and customize the frontend for their own applications. How would the browser plugin properly attest the frontend code hasn't been modified if an application dynamically generates custom frontend code per user?