Actually that's not what I'm saying at all. I'm critiquing the implementation of this for several reasons:
-The JS crypto can be trivially MiTMed. Your approach of checksumming the JS you outlined in another comment using external servers is laughably terrible
-The OTR is pointless. The keys aren't being verified so, again anyone could MiTM the key exchange and trivially intercept messages, even if there was no JS. This is the main point of the app, and it's completely broken.
-The entire application is relying on the security of the TLS PKI, which is horribly, horribly broken. This opens it up to attack by a huge number of people.
-It's being run on a shared server, with access to the keys by the real owners. Not to mention VM memory-leaking attacks by other residents, etc. Having your entire application logic hosted online and delivered to your users every time they access the service has security ramifications, whether you'd like to believe it or not.
So basically what YOU'RE saying is trusting 1 developer and trusting millions of people is the same because at some point you cannot verify every bit in the executable. Using browser crypto is worse than executables for the same reason PFS is better than non-PFS, you can't retro-actively hack or MiTM something. If both parties already have the executables stored locally (or delivered securely by an offline medium like USB stick and verified) the only way to intercept the data is compromise both end-points.
TL;DR your hyperbolic "trust as slippery slope" argument is dumb
-The JS crypto can be trivially MiTMed. Your approach of checksumming the JS you outlined in another comment using external servers is laughably terrible
-The OTR is pointless. The keys aren't being verified so, again anyone could MiTM the key exchange and trivially intercept messages, even if there was no JS. This is the main point of the app, and it's completely broken.
-The entire application is relying on the security of the TLS PKI, which is horribly, horribly broken. This opens it up to attack by a huge number of people.
-It's being run on a shared server, with access to the keys by the real owners. Not to mention VM memory-leaking attacks by other residents, etc. Having your entire application logic hosted online and delivered to your users every time they access the service has security ramifications, whether you'd like to believe it or not.
So basically what YOU'RE saying is trusting 1 developer and trusting millions of people is the same because at some point you cannot verify every bit in the executable. Using browser crypto is worse than executables for the same reason PFS is better than non-PFS, you can't retro-actively hack or MiTM something. If both parties already have the executables stored locally (or delivered securely by an offline medium like USB stick and verified) the only way to intercept the data is compromise both end-points.
TL;DR your hyperbolic "trust as slippery slope" argument is dumb