Should be much quicker to develop a common library for use by the server and a (webstart) client - than to do two separate implementations? Also some of the code (and most of the interfaces) could probably be used on Android as well.
If you are doing javascript wouldn't nodejs on the server make sense?
That said, we plan to generate keys like bitcoin does, so there if you have a bitcoin library in your language of choice, that part is done.
The server code will probably be less useful because there are so many choices, everyone's got their own preferences, and the server is pretty dumb compared to the client. Our leaning is to go with apache tomcat mainly because it's apache and it's widely deployed and, not least, it's what we use.
* If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different.
* Even if your users are sophisticated, they effectively have to install the code every time they use it, so any inspection they did yesterday will help them not-at-all today
* Browser Javascript code is influenced from all sorts of places across the DOM, meaning that you need element- by- element, attribute- by- attribute inspection of the entire page context (and this is before we get into things like caching) to have any clue what a piece of JS code might be doing
* The browser itself offers you no mechanism to hash and verify the whole runtime, so there's no way to lock in a specific inspected cryptosystem; even if you have the SHA2 hashes for your crypto .js, you won't have it for every point in the DOM that can override methods in that code
Leaning on browser javascript for cryptography is a bad idea that, I think, shows a fundamental disrespect for the security needs of actual real people who will be fooled into relying on it. I strongly advise you to go in some different direction.
Also, if a given, well-known resource could be pinned to a specific hash and third-parties could easily certify that specific hash, would that ameliorate the primary concerns with JS cryptosystems?
Thanks for your time.
Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends.
I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to let you do so.
Let me be clear that JS is not required; it's just how we're making our reference client because we don't believe most people are going to download a custom client.
You can write a working client with bash+openSSL+curl if you want. The whole thing is simply signed text snippets over http.
Still, if anyone has mission-critical privacy they want to protect, we expect there will be hardened native clients to choose from.
Most posts from most people are going to be public anyway. We keep the public stuff public, but signed and search-indexable, and we let you do private stuff securely if you want to.
Just like how sending a gpg encrypted email to (some) users of hushmail wasn't secure, because in the end hushmail encouraged insecure handling of the private keys.
In the end, the only rational, informed choice, is to regard the whole system as (in)secure as its least secure part.
If there is to be any point to a "secure social network", the trust you can place in the network (implementation) should be at least as high as the trust you place in those you share with?
Will you be able to take reasonable steps to prevent private keys to be written to (unencrypted) swap, for instance?
Promising a "secure" social network, kind of implies that data you share is secure from your spouse, for example.
