UI is absolutely a very difficult part of the problem, and here we see an example outlining this. Even a capable protocol still has problems if the UI fails to translate the capabilities into benefits and security increases for users. I speak from experience: Cryptocat has had some serious issues that were due simply to incomplete UI, the most recent of which was related to authentication.
Also, the reason for us moving to a new protocol has more to do with formal security proofs than being able to adopt new properties.
It really seems like you wrote this comment not to add anything to the conversation, but simply to discourage me from commenting. I really don't understand. I'm trying to be constructive here and I wish you'd join me. Your comment right now just flails around for abrasive things to put together into a statement that is completely incoherent and off-topic.
Your inability to respond to my actual comments appears almost willful. Let's break this down:
* You complained about TextSecure's "lack" of transcript integrity.
* I pointed out that transcript integrity was a prominent feature of the blog post we're talking about, and a feature that the actual TextSecure protocol does vastly better than mpOTR.
* Someone else objected to allusions to TextSecure's transcript consistency feature as vaporware, given that Cryptocat actually has a UI for this.
* I pointed out that the protocol Cryptocat builds that UI on is so bad that you conceded downthread that you're building a new protocol --- you made that concession in direct response to my point about mpOTR's inferior transcript consistency.
* Your response is to imply that improved transcript consistency is not a significant reason for abandoning your existing protocol.
* I point out the inconsistency.
* You object that I'm not "adding anything to the conversation".
Thanks for laying out your thought process, it's very helpful.
> I pointed out that the protocol Cryptocat builds that UI on is so bad that you conceded downthread that you're building a new protocol --- you made that concession in direct response to my point about mpOTR's inferior transcript consistency.
This is the problem. You're assuming that my mention of mpCat was a concession made in "direct response" to your point about mpOTR, whereas it's actually brought up as a tangent. The reason we're building a new protocol is to be able to subject it to formal security proofs, as mentioned prior. It doesn't have to do with the existing protocol being "bad" or not or its current integration into the UI.
Regarding my other implied statements, I think it would be better to stick to claims I am explicitly making instead of assuming implications on my part. That being said, I apologize and will try to be more clear in my future comments in order to avoid assumptions.
I'm also not sure why you keep bringing up mpOTR. As I mentioned in my other post that you refer to, we're not using it anywhere nor do we plan to. We're building a modified version which is far less bulky, etc.
Maybe some other reader can tell me whether Nadim is saying that he endorses TextSecure's continuous transcript consistency model and is working on folding it into his new protocol, or whether he thinks the mpOTR model of consistency checking only at the conclusion of sessions is so useful that not providing it is worth dinging TextSecure over, or whether there's some third option I'm excluding. Because I can't even figure out what Nadim is trying to say anymore.
I endorse continuous transcript consistency, but believe that TextSecure currently does not allow its users to benefit from it and that this should be resolved. I think mpOTR is irrelevant to this discussion. I hope that's clear!
Also, the reason for us moving to a new protocol has more to do with formal security proofs than being able to adopt new properties.