A downloadable client that doesn't bootstrap its own crypto every time it runs from your server.
Can I have my $1000 now? Actually: I'd prefer if you just sent it to Partners in Health; they're great.
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.