Even if they have been able to successfully get in-browser code signing working, how can they possibly gaurantee no leakage of data? I mean, there are so many inroads, from mitm to rogue browser plugins... It seems (near) impossible to secure them all.
Rogue browser plugins can be discounted as that's tantamount to a compromised device in the context of a downloaded E2EE app. MITM, well it's E2EE with trust-on-first-use for the crypto logic and implements the works when it comes to web security protocols, such as HPKP. There's enough mitigation there. TOFU in this context would mean once you visit once, the logic that's pinned in the browser then performs signature validation on crypto logic from then on.
No one's gonna get it perfectly right. Signal's probably the closest in terms of the cleanness of the protocol. It'd be neat to see Cyph implement the Signal Protocol in-browser as well, but that's neither here nor there. Ultimately, all of this will shift an attacker's focus away from owning the messaging application (or any component of it, be it the servers, the connection, etc.) to owning the devices and the users directly.
Your next technical battles will be in device security and user-friendly secure authentication. Your existing wars against your users (think phishing) will continue to heat up.
This is a weird response. The comment you replied to suggested (very accurately) that there are lots of different ways that browsers leak information, and gave the example of rogue plugins. You (accurately) dismiss rogue plugins, and then go on to write as if that were the only, or even the most important, vector for leaks. But, obviously, no.
Can you cite some other ways browsers leak information besides browser plugins? It's you who are making the extraordinary claim, that Cyph has come up with a way to make browser crypto reliably secure. I think the onus should be on you to demonstrate how carefully you've thought this out.
I'll make you a deal: if you name all the ones I know about, I'll tell you so. :)
