This article discusses some of the threats considered and the tradeoffs made around them.
Conversations do not provide forward secrecy. If a Secret becomes known to an attacker, all contents of that Conversation are visible to them.
Identities should be protected against tampering. This can be done by using design documents to render the public key document read-only after it is first written. If an attacker were able to overwrite a public key document in a way that was not obvious to readers, they would be able to intercept any new invitations to that Identity. It would then be up to the owner of the Identity to disavow the Identity through other channels. Importantly, this attack would not compromise the security of any existing Invitations or Conversations.
Conversations are publicly readable and writable. Without the relevant Secret, the Messages are gibberish so an attacker does not profit by gaining access to them. There is, however, a Denial of Service threat through an attacker POSTing random data as Messages. Clients could trivially filter these out from appearing to the user, however they would only be able to do so after downloading and attempting to decrypt them. This is mitigated by only publishing the URLs to Conversations as part of encrypted Invitations. URLs to Conversations should be complex enough to avoid attackers being able to easily guess them.
Attackers may attempt to ascertain who is conversing by watching the metadata flowing into and out of the central CouchDB installation. Watching this from the outside (say, packet sniffing on datacenter’s network) would be useless so long as SSL is enforced on all connections. Attackers would be able to ascertain who is using UTR, but not who they are conversing with. Being centralised actually provides better security here, as if a user hosts their own Identity it becomes easier for attackers to know who is sending them Invitations. If a user hosts their own
Attackers may attempt to ascertain who is conversing by watching the metadata flowing into and out of the central CouchDB installation. Watching this from the outside (say, packet sniffing on datacenter’s network) would be useless so long as SSL is enforced on all connections. Attackers would be able to ascertain who is using UTR, but not who they are conversing with. Being centralised actually provides better security here, as if a user hosts their own Identity on a server with no other UTR traffic it becomes easier for attackers to know who is sending them Invitations. The same holds true for Conversations. There is anonymity in the herd.
Attackers may use the legal apparatus to force the entity hosting the central server to log and hand over metadata from within the application server itself. This is difficult to defend against legally, but the technical implementation gives us some extra degrees of freedom. If the controlling structure of the host entity was set up in such a way that it could still take overt actions after recieving a court order, and the entity still had control of their domain name, it would be possible to move all Conversations to another jurisdiction with minimal user impact. Even if the data could not be transferred to another server, each user has a durable store of the conversatiosn that would automatically repopulate the central public repository the next time they reconnected.