[liberationtech] What I've learned from Cryptocat

[Gregory Maxwell]

On Mon, Aug 6, 2012 at 6:53 PM, Nadim Kobeissi <nadim at nadim.cc> wrote:
> The blog post suggests that becoming a local browser app means that
> Cryptocat no longer uses JavaScript cryptography. This is nonsense:
> JavaScript is a *language*, and since browser apps/plugins are written in an
> HTML5 framework, we will still be using JavaScript to implement
> cryptographic functions. The only thing that has changed is *the method of
> code delivery.*

This makes me a little sad.  Previously, I understood what cryptocat was for:

It was an insecure system, which was still probably significantly more
secure than the common default unencrypted system, for use where
deployment/usability issues meant it the choice was
insecure-hosted-software or totally-insecure-plaintext.
Non-server-replaceable systems like OTR were strictly preferable, of
course, but in reality aren't ubiquitously used like they ought to be.

With it becoming a browser extension— it seems like it would gain
much, although not all, of the usability challenges that precluded
using OTR in the first place and in those places where the extension
can't be pre-installed we still have short term SSL CA trust
challenges (for the on-demand distribution of the extension). It also
still retains many of the JS crypto specific technical challenges (no
mlock, so no way to prevent long term keying material from hitting
disk; generational GC so overwriting can't be trusted to reduce cold
boot attack exposure).

No doubt you'll find this an unwanted barb when you're already working
hard trying to make good software to protect people, and that isn't my
intention... but I don't know how to illustrate my confusion
otherwise.