I absolutely do hear what you are saying, and I understand your point.

I think where we disagree is in our assessment of the developers. You think that they are incompetent and unqualified for the task. Whereas I think they are likely qualified for the task (I give them the benefit of the doubt) and the crypto community is overreacting in their criticisms of the issues, making minor mistakes seem much graver than they actually are.

I've seen cryptosystems written by brilliant people and thought solid for many years later to be shown to be vulnerable. We still today continue to find issues in critical crypto libraries used around the world. Should we just throw them all out? Declare the authors incompetent? Anybody can make mistakes. And I don't think this making of mistakes invalidates anyones right to fix their mistake and keep pushing forward, as you evidently do.

> I understand your point.

No, you don't, because you continue to make worthless tautological statements like "anyone can make mistakes".

I've designed an airplane. I have no experience in doing so. I have no more than a layman's understanding of aerodynamics. I know nothing of materials science. I've hardly even looked inside any kind of engine. I have heard some fancy words before, though, and I'm sure my quick read of various Wikipedia articles has prepared me.

I'm going to start building these planes and selling them to the public as a great way to travel.

Do you think it is overreacting for an aviation engineer to tell people that my plane is dangerous, just because Boeing sometimes makes mistakes?

If you don't, then you shouldn't have a problem with the public being told that Cryptocat is dangerous.

If you do think it's overreacting, well, as it happens I'm no more competent to deal with insanity than with aeronautics.

His "jerks" point still stands though. You just called him insane because he made a couple of careful wrong assumptions and tried to verify them.

Yes, crypto is serious stuff. Yes, people should be warned about insecure security products. No, you don't have to be a jerk while doing that. See for example jdiez17's reply for what I think would be an effective and persuasive approach.

> You just called him insane

No, I didn't. I called a hypothetical and clearly homicidal person who I doubt was ever participating in this thread insane.

You can try to weasel out of it, but for all intents and purposes you did. Here is how you did it:

1. You compared the situation A to a hypothetical situation B, claiming it to be equivalent or comparable - A <=> B

2. You claim that someone describing the hypothetical situation as an overreacting description of the hypothetical situation - Describe (P, O (B)) => Insane (P)

3. By extension you imply that the person considering the first situation overreacting is also insane - Describe (P, O (A)) => I (P)

    (A <=> B, Describe (P, O (B)) => Insane (P))
      => (Describe (P, O (A)) => Insane (P)

Its probably unintentional as you did attempt to soothe it out (but that didn't help)

Personally I find that using the "understanding" method works much better than the "sootheing" method i.e.

"I understand why you think this way - <explanation of your understanding of the thought process of the other person> but you're wrong because <explanation where thought process goes wrong>"

You're insane. I say that not because you disagree with me, but because you have tried to turn an informal discussion into a math problem, apparently thinking it would be in any way persuasive.

For the record, the final line of my comment was intended to mean, basically, "If you don't think airplanes built my amateurs are dangerous, then we're not going to get anywhere, because I would consider you insane."

Whatever else you got out of it is your own invention.

You're an asshole.

The problem is that your argument is based on false equivalence.

The counterpoint is the classic trade-off between usability and security. I would (as would many) argue that charges against the Cryptocat team of poor cryptographic implementation or indeed knowledge are rational, appropriate and correct.

Charges of unbounded incompetence are irrational, inappropriate and incorrect. The cryptocat team understand usability, UX, general architecture and programming. That does not chime with sweeping statements of incompetence. Where they fail (and you may see this as a fatal flaw, it may surprise you to see that others may not but it appears that others do) is at crypto.

When it comes to real world attacks so far, it seems that Cryptocat is dangerous, but as dangerous as using any other TLS website. I totally accept that there is substantial evidence pointing to a lack of understanding of cryptography, but unbounded claims of incompetence only undermine a cryptographer's position.

There is no trade-off. A product is either secure for its intended purpose, or it is not. CryptoCat is not. An insecure crypto product is a useless crypto product, and no amount of user-friendliness will make it useful.

There is no "charge of unbounded incompetence". The charge of incompetence is concerned with cryptography (though there is evidence of surprisingly basic programming incompetence, too). Their competence at UX or anything else is totally irrelevant.

> A product is either secure for its intended purpose, or it is not.

I'm going to have to respectfully disagree here. All products have bugs and a proportion of those bugs will be security-related. Crypto buys you temporary secrecy, based on the class of crypto used and the technology available to break it. DES was considered fine decades ago because even though it had weaknesses it was considered to provide sufficient protection of assets carrying certain classifications of data for a certain period of time.

AES256 is good for a period of time dependent on the projected capabilities of your perceived adversary and the sensitivity of the data.

> There is no "charge of unbounded incompetence". The charge of incompetence is concerned with cryptography (though there is evidence of surprisingly basic programming incompetence, too). Their competence at UX or anything else is totally irrelevant.

Where do I start with this? First you say there's no unbounded charge then go off charging Cryptocat in two areas. The UK "or anything else" is not totally irrelevant. The whole purpose of Cryptocat is to provide an easy to use chat system that encrypts conversations. Note that easy to use comes before encrypt in the description on the front page of the website. Nowhere on the front page does Cryptocat say that they're secure, because they know they're not.

The point is that writing software that uses cryptography is unlike writing software that, say, uses a Twitter API library. In the latter case you can detect errors quite easily because functionality will be compromised if you make a mistake. This is not so in programs that use cryptography; they tend to work without noticeable problems, but they may be shooting themselves in the foot.

It's all about preventing known mistakes. For example, say a developer uses a One Time Pad encryption scheme in their application and calls it "secure". Surely if we've had any contact with cryptography we know that a OTP with a reused pad is broken and leaks key bytes, and vulnerable to many other types of attack.

These mistakes can be avoided by having proper education in cryptography. I understand cryptocat's developers urge to write it in the same way they've written software the rest of their lives, through trial and error. And that is okay for most software, but not cryptography.

> And that is okay for most software, but not cryptography.

I'd be fine with it if they just slapped big red letters across the top saying "WARNING - EXPERIMENTAL". Why? Because people do need to experiment with topics and that doesn't hurt.

What's upsetting is they're basically claiming their product is on the same level as lots of products that have been heavily tested and verified by groups of people when it's an amateur experiment in the topic.

That might be fine for most kinds of software, but is irresponsible in crypto, embedded safety systems, etc.