Not replying on whether or not Web crypto is effective because you and William seem to have that discussion covered pretty well (and honestly it's too long for

Not replying on whether or not Web crypto is effective because you and William seem to have that discussion covered pretty well (and honestly it's too long for me to read right now), but you're right that we should have had an option to authenticate the OTR; thanks a lot for pointing that out! I just deployed a fix that I think is actually pretty clever (haven't seen anything similar done anywhere else, anyway). Rather than intruding on the existing UX, I'm just automatically generating a shared secret on the first client and putting it in a fragment at the end of the generated URL, which is then used by both clients for SMP. So now, to successfully mitm a Cyph chat server-side an attacker would have to have compromised both our server and the users' SMS/email/etc., and even then they'd still have a pretty small window of time in which to execute their malicious code on the Cyph backend. It's not strictly foolproof, but it's still a hell of a lot better than leaving unauthenticated as the default. Combined with the two-factor auth feature we're rolling out in a few weeks, this should put us in a pretty good state. The only (mildly) inconvenient thing about this solution is that it precludes us from adding buttons to automatically text/email the link to your friend for you (since that would involve passing the secret to our server). re: checksumming, the plan is to do it client-side, not server-side (I could have misread/misskimmed but it sounded like you were mistaken on this), and have the user manually agree before applying any updates to local appcache. The idea is essentially to cram a traditional release cycle into the Web, with a stable channel with biweekly formally audited known good payloads. Still need to prototype this and see if it's feasible, but on paper it sounds good to me.