> 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.
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
