A host-proof application is one where the user doesn't have to trust the host.
The users data will be encrypted and decrypted on the client side, and the server only stores the encrypted data. This way you would get the benefit of a cloud application (accessible from anywhere) while retaining the security of only having access to the data yourself.
Hence you don't have to trust the host, because the host only has the encrypted data which is useless without the decryption keys.
SendItOnTheNet is a host-proof application.
Your files are encrypted on your computer before being sent to our servers, and you never give the server the key. Therefore we absolutely cannot read the data in your files, it is absolutely impossible. If we can't read your files then that means your data will never be released into the wrong hands, even if someone broke into one of our servers (both physically and over the net).
The answer is Public Key Cryptography
a message encrypted with a recipient's public key cannot be decrypted by anyone except a possessor of the matching private key—presumably, this will be the owner of that key and the person associated with the public key used [wikipedia]
No you don't even need to trust us. When you navigate to the secure section all the code is sent down to your web browser, before you login. This means (if you so wish) you could look through the code to make sure that it can't steal your password or keys. If you don't want to do that you can feel comfortable knowing that other people will be auditing it for you.
We believe in being transparent, and we'll let you know about any potential weaknesses in our design. For example a feature we are waiting on is called the HTML5 FileSaver to be available in more browsers, since this isn't available yet we have to use a flash based downloader called Downloadify in FireFox. This presents a small degradation to our hostproof credentials as you can't audit this before logging in. It is open source which means it can be validated which should go some way to alleviating any concerns.
The second issue is we provide you with the public key of your recipient, this means that it is theoretically possible for us to give you the public key of a different user when you go to add a contact. You can mitigate this by verifying the public key with the contact before confirming them. Also once you first add the contact you store your contact list (along with their public keys) encrypted on our server, so the weakness is limited to just when you first initially add a new contact, not every time you send to them.
We love talking about host-proof hosting (the upsides and the downsides) so please get in touch if you want to talk about it in more detail.