[makomk]

It doesn't matter what kind of transport integrity the underlying protocol has if that integrity information isn't actually used. What's more, it's not just that they haven't got around to implementing UI for it, the problem is they can't figure out how to meaningfully expose that information in the UI - which, with consistency semantics this complicated, is actually the hardest part of the problem! They don't even really have the outline of a solution, let alone the transcript integrity you're claiming they have. Yet here you are treating their vapourware as though it provides more protection than something that actually exists.

[tptacek]

The UI for transcript consistency is absolutely not the hardest part of the problem. We are comparing an existing UI on top of a broken transcript consistency feature to a nonexistent UI on a functional, extant transcript consistency protocol. I am objecting to the notion that an extant UI built on a mound of sand somehow trumps a concrete foundation poured for a better UI.

This is apparently so much the case that Nadim has acknowledged jettisoning his existing protocol to come up with a new protocol that will support it.

You could disagree with me, but I don't think you can do so without acknowledging that the comment that introduced this issue to the thread was... let's say "not fully informative".

[kaeporan]

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.

[tptacek]

This is a comment that appears to endorse mpOTR's broken transcript consistency feature. Also: formal security proofs? Really?

Some context: http://tobtu.com/decryptocat.php

(Yes, we know you addressed these issues; the page I just linked to says that).

[kaeporan]

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.

[tptacek]

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".

[kaeporan]

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.