Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point completely.
To the other point made above along the same lines, the protocol is the key and you are free to choose your own client. No matter which you choose, you have to trust the source.
Our goal is to get the protocol adopted and used as widely as possible. Mass adoption is only possible if there's a web client with JS crypto, and there's no way around the need to trust the server you download it from.
Assume for a moment that JS crypto is insecure. If you use a web client with JS crypto to bootstrap acceptance, then the majority of your clients will end up using JS crypto. If the majority of the clients on the 'network' are insecure, then what's really the point?
A single client isn't weakened by other compromised clients.
If you run a hardened trustworthy client, your own public posts are still verifiable, and private posts meant for you are decodable only by you.
You would just need to make sure to send your private posts only to others that use trustworthy clients. But, because you're sending them a secret message in the first place, you already implicitly trust them.
> You would just need to make sure to send your private posts only to others that use trustworthy clients.
And how would you make sure of that? Is there a field in the user data that says: "419 I speak the protocol, but I don't give security grantees - fool you for talking with me?". Is there planned an easy UI for showing you which of your contacts are part of the secure network, and which ones are backdoors into the network?
I'm not being flip about it. Granted, entropy is an issue with in-browser JS, but the rest of it is really just cautionary about browser bugs, compromised browsers, and known page-based browser attacks. Very little doesn't also apply to every crypto system on every platform. If you can't trust your OS or browser, you've got bigger problems.
I'll submit that because it's in-browser it's additionally difficult - very difficult - to get right, but I don't see that it's impossible.
Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point completely.
To the other point made above along the same lines, the protocol is the key and you are free to choose your own client. No matter which you choose, you have to trust the source.
Our goal is to get the protocol adopted and used as widely as possible. Mass adoption is only possible if there's a web client with JS crypto, and there's no way around the need to trust the server you download it from.