Hi, Lobste.rs! Founder here (on my 2nd “startup”).
I strongly believe in the need for private communication, especially in the context of doctors-patients, clients-lawyers or sources-journalists.
PGP has done a great job of allowing private communication between two parties, but it places a heavy burden on both the sender and the recipient. Often though, the person who needs to send the private communication is less tech-savvy than the recipient. Private Forms removes the burden from the sender, and places it squarely on the recipient.
With Private Forms (https://privateforms.com) you can create an embeddable web form (with custom fields) that encrypts messages client-side, before being sent to the server (and emailed to the recipient). These messages are encrypted using the recipient’s PGP public key, which can only be decrypted using their private key—this way, not even we can view the form submissions. We can help less technical users by generating a keypair for them (again, client-side), or they can upload their own public keys.
Recipients can view form submissions on the web (using their private key, which is never transmitted to our server), or via their own email client that supports PGP decryption.
This is very much a MVP, with regards to the interface and the number of features, but I wanted to get this out in front of as many people as possible!
What prevents an attacker from injecting code into the page to scoop data on the client side before it’s encrypted?
If the answer is ‘https’, what security benefit does this scheme give over https with no client-side encryption?
“https” is the answer you’re looking for!
Beyond that, it gives an extra layer of security, in that the host (me) can’t read it, and that the data is never unencrypted, at rest.
The problem is that you can read it: all you need to do is inject JS to extract the message. The users have to trust you not to do this, but in that case they can just trust you not to look at the messages.
Similarly, an attacker who can break TLS can do the same thing, so this provides no additional security layer beyond TLS…
If one has reason to be this privacy conscious, wouldn’t one also want to host and serve the JS that does the encryption? If I don’t trust a third party to store the data, why would I trust them to serve up the code that encrypts the data?
This seems like something that can be thrown together in a couple of hours using open source libraries without having to rely on a third party for hosting (or relying on a significantly more mature one) or pay a monthly fee for. What am I missing?
Privateforms is using kbpgp, which is licensed under a 3-clause BSD license. I don’t entirely understand the point of this either.
It seems to me that this isn’t useful for many of the use cases that you typically would utilize a form for.
Q: Can I use it for a signup form?
Q: Can I use it for placing an order, sending electronic medical records, etc?
A: For a store that doesn’t have an eCommerce site, but simply an “order form” where you enter your credit card details and things, possibly. But, the receiver of the encrypted data probably needs to take into consider PCI compliance, and other things. And, to @anfedorov’s points, do I trust Private Forms to not snoop sensitive data? For things like medical records, it’s almost certainly not HIPAA compliant, or any other compliant either.
Q: Can I use it to contact my friend, or send mail anonymously?
A: Possibly! But, Private Forms is receiving the POST data, and even if it’s properly encrypted, there’s a lot of stuff leaked in the metadata. My IP Address might end up being stored on Private Forms servers, so there’s no Anonymity guaranteed.
Q: Can I use it for a survey, or to cast a vote?
A: There doesn’t seem to be any way for Private Forms to limit the submission process to 1 per client. I guess it’s possible that it could do some sort of token generation, but now Private Forms has to know something about your data (even if it’s just how many people you sent the form to). That seems to go against the Privacy Conscious recipient claim…
All in all, it’s a cool idea, but I see too many flaws and not enough use cases…