[liberationtech] DecryptoCat

Tue Jul 9 09:31:45 PDT 2013

> What I hear from you is a common idea: it is the idea is that people who don't
build those systems don't have a right to voice negative or critical views.

Absolutely not. If this is how I came across, I apologize.

Let me try to express myself a little more clearly, and not via a phone.
Your second reply resonated quite well with my underlying thoughts.

> When we degrade others for their criticisms by suggesting that they only get
to speak if they've met some arbitrary bar for entry is dis-empowering. I
know that we all do this but perhaps it isn't the best way to move forward?

To be clear, the only thing I take objection to in this thread are the
snarky, semi-arrogant replies that imply that e.g. Veracode's code reviews
are useless, and that all the developers behind X are incompetent, while
not actually providing a lot of constructive commentary. (Admittedly, I am
already slightly annoyed from reading other comment threads about this same
issue where the response was a fairly unanimous "Omg, Cryptocat sucks! What
a bunch of amateurs!", so this is more of a response to that collectively
than to the comments of Maxim, specifically. That being said, I care very
little for arguments from authority, unless they make sense.) There may be
a language barrier, but despite being a non-native speaker myself, the
comments still came across quite negatively.

By no means should Cryptocat be immune to criticism--it's clear that it
isn't--and there is no reason why somebody with knowledge on a subject
can't comment on deficiencies, even if they don't make a competitor, or
prove that they are able to. But there are several ways to do so--a few
that I've seen recently in connection with Cryptocat are: 1. To turn to the
developers of the software and/or contributing to the software itself, 2.
By flaming the software and its authors on mailing lists and on blogs, in
discussions that are most closely analogous to "lol, noobs.", and 3. A
combination: finding vulnerabilities, informing the developers, and posting
about it on blogs with added opinions that all the developers are
incompetent.

Obviously, I think #1 is the most useful. #3, while harsh, still is, since
the vulnerabilities will inevitably be patched, whether or not you provide
a solution. (Indeed, the history of responsible disclosure shows that this
is often the only way to get something fixed.) #2 is entirely useless, in
my opinion. So when I say "if it's so easy, make a better one", I really
mean "why don't you switch from #2 to either #1 or #3."

There obviously is a limit: where the authors of a piece of software are so
incompetent, or the software is so badly written, that it should be avoided
at all costs. I don't think that Nadim, et al, and Cryptocat are at or past
that point, for several reasons:

  - They very clearly communicate that this is experimental software, that
you shouldn't put your life on the line using it, and that it hasn't
undergone a lot of scrutiny
  - Whenever there's been a new feature or new release, the main request
from the authors themselves has been that people take a look at it and come
to them if they see any problems. The authors recognize that they are not
infallible experts on the subject. (Contrast with Silent Circle where their
whole argument is that "we are crypto experts and Navy SEALs, and you
should trust our closed source software", but the software still has
serious problems.)
  - Cryptocat is helping bring OTR to the masses

> I'm not sure if you're away but Maxim did exactly this many years ago.
> He wrote a system called cables:

I was aware of its existence, although I'll admit I haven't used it
recently.

While I appreciate and recognize your description of its ease-of-use, I
will say that I think most people aren't going to run a custom Linux
distribution to communicate securely--and when I say most people, I mean
"the masses", not liberationtech. Which leads me to my main point...

> Usability is absolutely critical - but we're not looking to build usable software
without any security - if we were, we'd all be using Facetime, Skype, GChat
and so on, without any complaints.

This is where your reply is in agreement with what was (granted, deeply)
between the lines of my initial replies, where I continuously highlighted
usability as a critical feature.

I want secure software. I want something that lets me communicate with
others securely. But when I, a fairly paranoid person by my own judgement,
and somebody who writes cryptography and privacy software for a living,
disable my Android device encryption because it doesn't let you use
something other than the encryption passphrase to unlock the screen (even
though it doesn't actually dismount the disk when the screen is locked), or
use Skype and GChat to communicate with my friends because most other means
are just too cumbersome, I have to recognize that security, even perfect
secrecy, is completely useless if nobody is actually making use of it.

Cryptocat is a worthwhile effort, if only for this reason: It has a fair
amount of users, and it's helping popularize a very secure means of
communication, OTR. It has implementation errors--almost all security
software has--but the authors are well-meaning, transparent, and open to
constructive criticism. When a project like that has traction, you support
it if you genuinely care about user privacy. You don't berate it and scare
normal users away from e.g. MSN, indirectly maintaining the status quo.

> While Cryptocat has OTR - the multi-party communication is not the OTR
protocol.

Yes, I know. I was just saying that if it's incredibly easy to develop a
secure Cryptocat alternative, that's what it takes. If I'm not mistaken,
the bugs that we are discussing all apply to (only) the multiparty chat
component of Cryptocat, not the OTR one.

> On three computers near me, I see it using non-forward secret modes today
- SSL_RSA_WITH_RC4_128_SHA - this isn't good news.

I agree that this is bad, and I think the way you went about highlighting
this was positive and constructive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130709/a2d1eeb8/attachment.html>