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.
I appreciate your concern, but you can't fault JS for browser bugs or OS bugs.
It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server. What's worse, you didn't compile it from source, so how can you know there's nothing sinister lurking in there?
You are correct that people like native apps for their microblogging, and we want to encourage many native, hardened, peer-reviewed implementations for every platform imaginable.
Because the client is just appending signed entries to the end of an RSS file, send pushing and pulling those files over http, you could write a nice client running inside emacs (if you trusted your os crypto libs).
Your logical fallacy is: putting words into my mouth (argumentum ad logicam). I didn't say "why bother making the crypto" secure. I said that you can't point to endpoint security as a reason to fault JS more than you can fault every other crypto implementation.
Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised.
JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.
Yes, this is the kind of feedback we're looking for with regard to another comment here. This is why we haven't committed to a language for the server-side reference impl yet, because we're not sure what would be useful. (Our prototype is java, fwiw.)
Agree, wordpress is an apt comparable. Some of the KS tiers are that we're providing hosting for early backers, so we need to provide hosting for early backers.
The intent is to extend an existing standard, RSS, with an http protocol to support it. We need to one of many providers for the system to work as intended.
I get where you're coming from, but I was sitting at an Eclipse game with ESR last week (where he beat me on the tiebreaker but I digress) and he thought our approach was great. KS didn't exist back then. If it did, it might have funded some of the great foss projects. #truestory
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.
Well, it's kickstarter so we're deferring some decisions until it closes, and leaving room to listen to our backers.
I know you probably meant to snark, but to take your question seriously, the question we have is: do we open up our working prototype, or write a reference impl from scratch in a language more useful to our community.
If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.
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.
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.
That said, the js crypto isn't the part I'm worried about. It's all the scripting vulnerabilities to guard against in the browser.
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.
If normal people are going to use it, it has to run in a browser, hence JS. There are working open source crypto libs in JS today, and kind of the nice thing about them is that they're not compiled, so (if unobfuscated) you can literally just inspect the source.
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.
Our use cases are of Twitter too, so it makes a certain sense. We haven't designed the UX yet, but it's meant to convey the idea.
That said, the architecture supports not only Twitter but FB-style friending and private group shares; we want to encourage different clients in different form factors, with the advantage being that they'd all interop. No more siloes.
JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.
Our thing is that we: (1) extend RSS to support self-signed/self-encrypted entries, (2) specify rest apis for http servers to exchange RSS entries (kind of like NNTP).
We'll make a reference implementation, but we want and need many providers to experiment with price points and service options.
More importantly, anyone can roll-their-own provider on their server.
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.