There is no shortage of opinions on the benefits and limitations of browser crypto, and we are very familiar with both sides of the argument.  Like some of our previous answers, this one is going to get technical, so if you aren’t a geek you may want to tap your geek friends on the shoulder for help understanding this answer.  

There are typically a few common arguments against browser-based crypto.  We’ve done our best to address them and have outlined these below.  

Browser’s do not natively support proven cryptographic API’s

This is true in the case of native browser code, specifically JavaScript. If you are ultra paranoid, then you should use one of our code-signed clients to access SendSafely. We offer three code-signed clients: The SendSafely Java Applet, SendSafely Chrome Extension and SendSafely for Outlook.  

There may be cases, however, where you may not have access to a machine with our client installed and the only easy option is to use our native HTML5 JavaScript client. We only use open cryptographic standards, and have chosen to use the OpenPGPJS^[1] JavaScript implementation of OpenPGP.  This library has been openly reviewed by the security community and we stay up to date on all releases.  

Reliance on Server-Based Security and SSL

Many browser-based crypto are often reduced down to the security of the server that hosts the client side code along with the security of SSL.  So for example, if the client that does the crypto is hosted on our server, then in theory anyone who compromises our server can alter it and add a backdoor.  Likewise, relying only on SSL to ensure the integrity of the client from when it leaves our server to when it gets to your machine could be a problem if someone is able to “middle” or otherwise compromise the security of the SSL connection.

Fortunately if you are paranoid, our Java Applet client will cover you on both of these concerns. Our applet is signed with a Java Code Signing certificate issued to our company. When you go to run our applet, you will be prompted to give our applet permission to run and can verify the authenticity of the applet signature.  If anyone has tampered with the applet, either in transit or on the server, the signature will fail. In the case of the JavaScript client, there is unfortunately no good alternative for mitigating this risk. The good news is that the majority of sensitive stuff you do on the internet every day, like paying your bills online, reading your personal email, and even accessing your company’s VPN, all also rely on the security of SSL and server-based security.  While we as paranoid security people may not like it, we must live with it as our reality.

You need to trust the Software Author or Server Operator

The last common threat is not one that comes from the wiley hacker, but from us.  At the end of the day, running our signed code is only as trustworthy as we are.  At Gotham Digital Science, we made a name for ourselves as a trusted advisor to numerous Fortune 100 companies and other large organizations around the world.  Our reputation is something we value deeply, and would not jeopardize.  We have made every effort to develop a trustworthy platform for securely sharing files, and will do our best to ensure the security and integrity of the platform.  We’ve also made every possible attempt to reduce the amount of trust you need to put in us.  Our Java client is not only signed, but its also open-source so you can review the code yourself to keep us honest.  We also welcome feedback from the public and security community, on suggestions to improve the way we do things. Our mission is to be as secure and transparent as possible, so that even if you don’t need to trust us...you can.

Compromising JavaScript Crypto through Cross-Site Scripting (XSS)

Another common concern with JavaScript cryptography is that the code could be compromised through a cross-site scripting vulnerability within the site. We make use of the emerging Content Security Policy (CSP) standard on our site to prevent newer browsers from ever running JavaScript code unless it gets served from our static sandbox domain.  We recognize that CSP is just a safety belt to protect our site from XSS, so we also employ rigid best practices in our code to make sure every piece of dynamic input gets escaped properly.