Ken Lee.dev

Web apps

Nobody opens an attachment called securedoc.html

In development. Recipients always free, and the key is not mine.

Not for sale yet. In development. This page exists so you know what is coming, and so you can tell me if it is the one you want first.

If you have ever received one of those bank emails with an attachment named securedoc.html, you know the feeling. A file that looks exactly like malware, asking you to open it and then log in to something. Most people delete it, and the ones who do not have been trained to do the precise thing security advice tells them never to do.

Half the point of secure messaging is the recipient trusting the message enough to read it, and that attachment destroys the other half. So this sends from your normal inbox, and your recipient clicks through to a clean page with your branding on it.

Recipients are always free. Charging the person receiving your message is an excellent way to guarantee your message goes unread.

What zero-knowledge means when the app is a web app

Reasonable objection: if it runs in a browser and the data is on a server, how is it private? The answer is that what sits on the server is encrypted with a key I do not hold, so it is stored but not readable.

That is genuinely different from a service that encrypts in transit and keeps a copy of the key so it can offer you a password reset. Convenient, and it means somebody other than you can open your messages. I would rather you check that claim in the product documentation than take my word for it here.

FAQ

Does my recipient need an account?

No. They verify and read, and that is the whole interaction. Requiring an account to read a message you sent them is another way of making sure it does not get read.

What if you shut it down?

Fair question to ask a one-person shop about a hosted service. What I can commit to is notice and an export rather than a shutdown email one Friday. I cannot put a contractual guarantee behind that yet and I am not going to imply I can.

How is this different from just using an encrypted email provider?

An encrypted provider requires both ends to be on it. This works with the email you already have and the recipient you already have, which is the only version of the problem most people actually face.

Related