Show HN: Private Forms: PGP-Encrypted Webforms for Privacy-Conscious Receipients
privateforms.com
privateforms.com
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!
Also, if you're a ProductHunt user, I'd appreciate some upvotes! http://www.producthunt.com/tech/private-forms
Basically, I plan to continue working on this, while supplementing myself with my regular day job, until an alternative makes sense.
For non-technical users, we offer the ability to generate a key pair for you. But for more advanced (or more privacy-conscious) users, we offer the ability to upload your public key (which is used to encrypt the form data).
As far as decryption goes, form data is stored in our backend and you can decrypt it via the web app if you trust that we don't upload your private keys. We don't upload them—they're all stored in your browser's localstorage—but if you want to use the web app, you still have to trust us (if you're unable to verify that we don't upload them).
The nice thing though, is that you don't need to use our web app to decrypt the messages—you can use any PGP-enabled email app, or the command line. We send all encrypted forms to you, via email, so you can choose how to decrypt them using your private keys.
So, you can use PrivateForms in a way that you don't need to trust us at all. It's all "host-proof" in the way described here: https://www.passpack.com/blog/2008/03/host-proof-hosting/
The only benefit I see is possibly some sort of legal thing or against an attacker that only has read access to server memory. What am I missing?
Privacy as a service/app cannot be sustainably delivered without being distributed, like TahoeLAFS or i2p. Company-run, centralized service/apps are SPOFs because they're at massive risk of being shutdown or blocked by friendly/unfriendly governments, at their whims, by whomever happens to be in power. The instant email option is partly distributed but the bigger risk is being in the US means US courts, FBI, local police, etc. can grab your provider's servers. name.com is also subject to both Irish and American laws.
Unfortunately, most founders of privacy apps are business naïve and unable to manage their attack surface, making them easy prey to non-technical but more business-savvy folks. This resistance is further compounded by the sunk costs-bias, because what's done is seen as an immovable foundation which can never be torn down and, therefore, it must be worthwhile in the face of overwhelming contradictory evidence (e.g., 1950's lifestyle worship leads to cognitive dissonance with climate change). In reality, a venture should be a viewed as a never-ending collection experiments, where the assumptions may be turn out to be terrible to excellent (hopefully nearer to this) and trends/disruptions may move out from under it all.
Good luck and I hope it makes a lot of money before it gets shutdown by Hillary or the Great Firewall of China.
That's not true. PF cannot view the submission /after it has been submitted, assuming your javascript does what you say it does/. Which means it protects people from someone knocking on your door asking for old data, but not from the FBI knocking on your door and asking to tap future submissions.
This is probably a reasonable tradeoff, but you have to be honest in this in your communication. "That is because your user's submissions are encrypted using your key (which we don't have) before being sent to our servers." is true, but it suggests this would always be the case -- also in the future -- and you simply cannot guarantee that.
This also doesn't protect the sender from a keylogger installed on their machine. Private Forms is just one additional layer of security.
I also intend to add a warrant canary, but I felt like that wasn't needed pre-launch. This is definitely a high-priority item though, now that I have launched.
Note this is nothing unique to PF and I'm not trying to be negative. Other projects do this client-side crypto and claim it's a fix, but it's not really. Without ways to verify the contents of sites, it's not really solvable.
You should just be honest about the limitations of the implementation and let users know this still requires trusting PF. I'm sure it's still rather marketable because the target market is probably just people looking for "secure forms" or "encrypted forms". You're better off focusing on how pgp is great, how you're based in a country with good laws, how your company has top notch opsec and auditing, etc.
Also, what's this? https://github.com/keybase/kbpgp/blob/master/LICENSE
We had a copyright attribution page that was totally buried (sorry!), but I just added it to the footer and FAQ.
1. On the front page "Only you have the encryption key" could be confusing to folks new to PGP, consider instead "Only you have the decryption key". Then elaborate below - your encryption key/pubkey is uploaded to your service and made available to any users of your form, while your encryption/privkey remains secret.
2. What's your experience doing crypto in browser Javascript? I looked at that earlier this year but it was still pretty immature. Things like Mailvelope are a good start but not 100% reliable.
I use mailvelope for reading Private Forms submissions in Gmail, and it's wonderful.
As far as crypto in the browser, kbpgp is a great tool, assuming your browser supports it.
We have just recently released the exact same feature. Not all JotForm users use it but the users who use this feature are really excited about it. http://www.jotform.com/encrypted-forms/
It is free upto 100 responses/month.
If you start telling me that I'm paying for security measures that have no effect on your service security guarantees, I think you're selling snake-oil.
At this point, I'm very reluctant to trust my data to your service.
You should use PF if you trust them not to be compromised (hacked or be malicious) and not to backdoor the software. It shouldn't hinge on the client side crypto.
Edit: See link below: https://privateforms.net/embed/rNKlzL
So you get jquery, moment, bootstrap + datatimepicker, kbpgp and a few lines of glue to use kbpgp to send and XMLHttpRequest, basically:
kbpgp.KeyManager.import_from_armored_pgp({
armored: '-----BEGIN PGP PUBLIC KEY BLOCK-----\n' +
/* key */
'-----END PGP PUBLIC KEY BLOCK-----'},
function(err, keyManager) {
kbpgp.box({msg: '**form=data**', encrypt_for: keyManager},
function(err, encryptedString, encryptedBuffer) {
//send result;
}
);
});Securing the data center is the least of your worries for such an attacker. I'd detail additional attacks that all subvert the encryption process:
1. Compromise the site's private SSL certificate. This allows the possibility of MITM attacks. There is some evidence that NSA is already mounting such attacks on the Internet.
2. Malware on the client-side. A compromised browser, or a compromised OS.
3. The US government mandating that NSA installs hidden firmware on all data center servers.
I argue that strong semantics are extremely important when building secure services. I thought their service offers one such semantic: client-side form data encryption. They do not offer JS code integrity or any guarantees about the client-side encryption not being subverted.
By telling people about datacenter security and then calling it a "a detail that some people who are security-conscious might care about" or "data center security probably does matter", you continue to raise the fog of confusion in people's minds. Instead, the FAQ could educate the users and separate client-side encryption (which is what the service offers) from client-side code integrity (which the service does not offer).
I know the marketing and home page need a lot of love, but I wanted to get this out in its present state. :)
Mainly, we aren't doing any validation because we don't want to do anything that will read your entries other than encrypting them. If this is a feature our audience is interested in though, there's no problem implementing it.
It's only something worth solving if it hits the log files.