Show HN: Private Forms: PGP-Encrypted Webforms for Privacy-Conscious Receipients(privateforms.com)
privateforms.com
Show HN: Private Forms: PGP-Encrypted Webforms for Privacy-Conscious Receipients
https://privateforms.com
41 comments
> this way, not even we can view the form submissions
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.
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.
That's an interesting (and accurate) point. An interested user could verify the source of the embedded page, and ensure that it doesn't change.
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.
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.
It does mean that users must explicitly and totally trust PF. From a customer standpoint, the product might as well encrypt on the server side (immediately discarding the plaintext, ala lavabit). What attacks does encrypting in JS actually prevent? How does it decrease the trust required? Customers must still trust, 100%, that PF is being honest (and not compromised). The fact that PF-provided JS does the crypto is a relatively minor detail in this scenario.
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.
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.
You have an interesting product. I like the simplicity of it both in terms of ease-of-use and ability to make it more secure later. Are you intending to keep this thing going or build it up for an acquisition? If the former, I might do a consult with you on bulletproofing it in the future once its grown enough to justify the cost. If you like that, just keep the implementation well-documented, modular, and basically easy to reimplement if necessary.
I didn't build this looking to be acquired, but it would be silly not to be open minded at this early stage.
Basically, I plan to continue working on this, while supplementing myself with my regular day job, until an alternative makes sense.
Basically, I plan to continue working on this, while supplementing myself with my regular day job, until an alternative makes sense.
Good to know. I have a demanding, day job right now too. ;) I'll bookmark it in case I get an opening in the future.
Are you using any open source projects?
I'm deeply curious about how you're doing the encryption and am usually skeptical of in-browser cryptography, though I'd love to be able to trust some of the crypto libraries that have been transpiled to JavaScript.
I am. I'm making heavy usage of keybase.io's kbpgp: https://keybase.io/kbpgp
How do users verify keys are correct and not being sent to your server?
This is important! Thanks for asking!
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/
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/
But the person entering form data - how do they know the JavaScript is OK? All users must trust the server to send js that'll encrypt correctly. This isn't visible to users. If you server is compromised, there is no way for users to tell, right? What actual reduction in trust is there for users with this system, versus one where the encryption happens on the server?
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?
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?
If Snowden or IS uses this service, it's still possible for governments to take you to court Lavabit-style (minus SSL private key) (or Mega or PirateBay) and get a court order to shut you down unless you have colo/VPS hosting in Iceland, Sweden or similar jurisdiction and private DNS registration with a registrar independent from most corporate/diplomatic pressures (definitely not name.com, maybe what piratebay uses: https://www.binero.se or similar with less inflammatory/infamous clients).
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.
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.
Forget even government attackers. The entire point of the product is to avoid trusting them. Except... you still utterly and totally trust them, as there's no way to verify what the form is actually doing.
Looks like it uses this internally: https://github.com/keybase/kbpgp
Also, what's this? https://github.com/keybase/kbpgp/blob/master/LICENSE
Also, what's this? https://github.com/keybase/kbpgp/blob/master/LICENSE
Yes, we make heavy usage of Keybase's KBPGP. It's a great project and we're very thankful that they released this under an open license.
We had a copyright attribution page that was totally buried (sorry!), but I just added it to the footer and FAQ.
We had a copyright attribution page that was totally buried (sorry!), but I just added it to the footer and FAQ.
Cool. A few thoughts:
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.
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.
Thanks for point #1. I'm going to change that right away!
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.
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.
Another example to how good ideas come out at the same time!
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.
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.
In response to user feedback, I've implemented a 14-day trial period for all subscription plans.
Nitpick: https://privateforms.com/faq should say "All you need is internet access and a browser that supports JavaScript!" (No space between Java and Script)
Fixed! Thanks for the good eyes :)
The FAQ describes how the data center is using super-sophisticated security. Why is this necessary if the data is encrypted at the client? (perhaps I'm missing something about the threat model).
I cannot try anything before entering my CC number (and paying, no free month or anything), nor finding any detailed information about the setup (apart from 'public/private key client side JS'). But the site/server/data center security probably does matter if the JS is hosted at their site / servers.
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:
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;
}
);
});I like your answer because you're describing a new threat model: an adversary tries to subvert the encryption process. Their service does not protect against such a threat.
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).
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).
There is no such thing as usable encryption without integrity (authentication). Client side crypto here changes rather little.
I've implemented a 14 day trial period, for users to test the service before staying with us.
It isn't important, but it's still a detail that some people who are security-conscious might care about.
I'm sorry but I beg to differ. Encryption is a very powerful tool -- the whole point of doing encryption at the client is that we don't care about data center security any more. As long as the data isn't lost, my data remains confidential. NSA, KGB, the Chinese hackers can't read my data. Period.
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.
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.
The client side crypto is only as strong as the server side security. If, as an example, I get DigitalOcean to reset the password on the VM (or any other way to access the web servers) then I can simply add another line to the JS to post the plaintext data to a server of my choice. Game over.
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.
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.
You aren't paying for it. It's provided my my server provider, DigitalOcean.
May I suggest you make this clear in the FAQ? In its current format, the FAQ makes it a big deal out of it without explaining that it's an additional security measure and that client-side encryption alone is sufficient to protect the data.
Any screenshots?
There's an example form that I just threw up right here: http://sjstrutt.com/contact/
I know the marketing and home page need a lot of love, but I wanted to get this out in its present state. :)
I know the marketing and home page need a lot of love, but I wanted to get this out in its present state. :)
Oh, and I have it redirecting to a "thank you" page on complete that doesn;t really exist, so you will get a 404. The "thank you" page is configurable.
Submit with empty fields renders a 404 on the example.
I've updated the thank you page. Sorry, I got the example up in a hurry :)
@davidcollantes Sorry, can't respond to your reply.
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.
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.
Any reason why you are not validating the fields, to catch empty ones? Curious.
That's called lean right? ;)
It's only something worth solving if it hits the log files.
It's only something worth solving if it hits the log files.
I wonder if Keybase could start to provide apis/web packages for something like this.
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