What's an alternative implementation that encrypts the data at rest and is more resilient to a compromised server?
Can I have my $1000 now? Actually: I'd prefer if you just sent it to Partners in Health; they're great.
I agree with you that there are risks to browser side crypto but how are they any different from upgrading software without reevaluating the security of each upgrade? Browser-based crypto also has benefits; most users prefer using web applications to installed all else equal because it's easier.
Edit: I have no specific problem running ssh as a Java applet if I trusted the site and connection. How do you determine when you're comfortable upgrading ssh or any other security program through your package manager?
A remote web site is consulted (usually via plain http, not even https!) and new code is downloaded. Signatures are checked locally (using gpg, which is itself bootstrapped from trusted installation media, and can be updated at any time like any other package), and then new software is installed.
The update cycle is longer, but it's still there. Under the threat model of "your source of software is compromised", no system is safe.
$ wget https://openssh.org/releases/openssh-blah.tar.gz ; tar -xf openssh-blah.tar.gz ; make && ./bin/ssh host
If such a thing were possible (and not hideously slow). I agree with what I believe is your thesis: good crypto is hard to do right and that you should be very careful with which sources of crypto software you trust. I just wanted to point out that trusting trust is a big problem in our industry, and isn't magically solved by using binaries on your local machine.
I say "arbitrary", because I assume you would want to serve this JavaScript solution from your own site, the way people do with jQuery.
On the other hand, if you do decide to serve it from one central place, then you could establish similar level of trustworthiness for that source, but your solution would still be at a disadvantage. Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes).
I agree. That doesn't change my point: JavaScript or binary packages, if you're running crypto you need to be able to trust the source of your software.
> Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes).
This analogy is strained. It only really applies if your site is vulnerable to XSS attacks. After that, JavaScript is generally far more restricted than your average userland code. JavaScript from one site can't modify javascript from another (well-constructed) site. Whereas you correctly point out that once you can execute arbitrary code with user level privileges, the game is usually up.
In particular, x session keylogging means you can grab a sudo password from a user once you can spy on their session, which any userland program can do. JavaScript from attack.com can't monitor keypresses on trustedbank.com unless it's explicitly included (which can happen by accident via XSS).
Look up the same origin policy to see the kind of constraints that are usually placed on JS code.
Except that all else is clearly not equal: your solution is insecure.
There is definitely something to building "hostproof" applications. Javascript delivered from the same host isn't how to do it. The long-term solution is probably some kind of packaged thing similar to a binary, and some means of separating out who controls the server infrastructure from who controls that code. Even if it's the same organization, there's no need for the code signing key to be "live" on the Internet, so someone who compromises front end servers shouldn't be able to compromise the binaries.
Browser java hasn't lived up to any of its promises, and I'm not sure about native code execution mechanisms. webcrypto might be a way to solve this general problem in the future.
There is of course the bootstrapping problem when you first visit a site, but there are out of band ways to try to address that.
The other option is just to give up and do mobile stuff; a mobile development framework combined with server-side development framework designed to build "hostproof" stuff would be pretty cool. You get a trusted platform, potentially can do trusted stuff server side too, have a reasonable third party for distributing updates (at least on iOS) with some level of auditing in case of a bad app being served, etc. The problem is that if you can't trust Apple, you're kind of doomed; the ideal would be a per-enterprise root of trust, where no one else has the ability to push OS/app updates, and can actually verify how the hardware works. There was some work done by NSA with Android in that direction.