I'm the CTO of Tunnel X, which provides secure, private, web-based messaging for everyone. Tunnel X is the third early-stage startup of which I've been CTO, and my sixth startup overall. I've been doing web development since 1995 at companies such as Razorfish, Organic, MLB, and TabletHotels, and for clients such as NBC, Warner Music Group, TIAA-CREF, BMW, Pfizer, and Guardian Insurance, since 1995. Most of my work has been in a Java EE context.

A bit about Tunnel X. There is no Tunnel X "secret sauce"; we recognize "secret sauce" as as a red flag for security software which is likely to be deeply flawed. We take to heart Edward Snowden's advice to people concerned about security online, that despite recent revelations, "encryption works; properly implemented strong crypto systems are one of the few things that you can rely on."

As such, we secure client-server connections via TLS 1.2 (when supported by the client), down to TLS 1.0 (in which case we alert the user to the fact that they need to either upgrade their browser, or enable TLS 1.2). We only enable SSL ciphersuites which support PFS; which don't include broken algorithms (RC4, MD5, etc.); which don't use weak keys; and which don't rely on algorithms which are thought to be compromised (e.g. Dual-EC-DRBG).

For user authentication, we forego username/password in favor of a binary key (in the form of a JPG photo which the user has taken themselves) and a PIN. This is inherently more secure than username/password; there is also the added benefit that users inclined to passwords like "passw0rd" and "hello123" won't be using them on Tunnel X.

We encrypt user messages and other data with 256-bit keys which we store encrypted, and which may only be decrypted using keys derived from the user's uploaded image key. Only when the user is logged on can messages be decrypted. Decryption on our servers is a cascade of AES, TwoFish, and Serpent. We believe that this type of superencipherment is probably overkill, but also that properly implemented (using unrelated keys, e.g.), it costs us little.

While our UI is web-based, we do not employ any JavaScript-based encryption.

Because of user sensitivity to privacy, we do not use cookies (even session cookies); rather, we persist sessions by means of two session IDs, a primary one sent to the server as part of the URI in the traditional way, and a second one which is sent via a request header. We also do not use Flash, Java applets, plug-ins, extensions, add-ons, browser apps, ActiveX, or any other "extra" browser functionality, since these "extras" so often become attack vectors.

Finally, we believe that even the most secure means of online communication (e.g. PGP-encrypted email) offer little or no real security if not installed and used properly by users. Thus, we offer this web-based solution which offers a high degree of security and privacy while being easy to use - and very difficult to misuse - for the average user.