7 ms·

Show HN: Private Forms: PGP-Encrypted Webforms for Privacy-Conscious Receipients

60 points by sjs382 11y ago

sjs382 11y ago
Hi, HN! 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 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 http://www.producthunt.com/tech/private-forms
- pipework 11y ago
  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.
  - sjs382 11y ago
    I am. I'm making heavy usage of keybase.io's kbpgp: https://keybase.io/kbpgp https://keybase.io/kbpgp
- nickpsecurity 11y ago
  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.
  - sjs382 11y ago
    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.
    - nickpsecurity 11y ago
      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.
- MichaelGG 11y ago
  How do users verify keys are correct and not being sent to your server?
  - sjs382 11y ago
    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/ https://www.passpack.com/blog/2008/03/host-proof-hosting/
    - MichaelGG 11y ago
      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?
      - ddoscampaign 11y ago
        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 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.
- bramblerose 11y ago
  > 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.
  - sjs382 11y ago
    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.
    - MichaelGG 11y ago
      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.
tortilla 11y ago
Any screenshots?
- sjs382 11y ago
  There's an example form that I just threw up right here: http://sjstrutt.com/contact/ 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. :)
  - davidcollantes 11y ago
    Submit with empty fields renders a 404 on the example.
    - sjs382 11y ago
      I've updated the thank you page. Sorry, I got the example up in a hurry :)
      - davidcollantes 11y ago
        Any reason why you are not validating the fields, to catch empty ones? Curious.
      - sjs382 11y ago
        @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.
    - bwblabs 11y ago
      That's called lean right? ;) It's only something worth solving if it hits the log files.
  - sjs382 11y ago
    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.
daveloyall 11y ago
Looks like it uses this internally: https://github.com/keybase/kbpgp https://github.com/keybase/kbpgp Also, what's this? https://github.com/keybase/kbpgp/blob/master/LICENSE https://github.com/keybase/kbpgp/blob/master/LICENSE
- sjs382 11y ago
  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.
locacorten 11y ago
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).
- sjs382 11y ago
  It isn't important, but it's still a detail that some people who are security-conscious might care about.
  - locacorten 11y ago
    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.
    - sjs382 11y ago
      You aren't paying for it. It's provided my my server provider, DigitalOcean.
      - locacorten 11y ago
        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.
    - MichaelGG 11y ago
      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.
philip1209 11y ago
I wonder if Keybase could start to provide apis/web packages for something like this.
bgibson 11y ago
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.
- sjs382 11y ago
  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.
sigjuice 11y ago
Nitpick: https://privateforms.com/faq https://privateforms.com/faq should say "All you need is internet access and a browser that supports JavaScript!" (No space between Java and Script)
- sjs382 11y ago
  Fixed! Thanks for the good eyes :)
sjs382 11y ago
In response to user feedback, I've implemented a 14-day trial period for all subscription plans.
aytekin 11y ago
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/ http://www.jotform.com/encrypted-forms/ It is free upto 100 responses/month.

60 points by sjs382 11y ago

Hi, HN! 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 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 http://www.producthunt.com/tech/private-forms

pipework 11y ago
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.
- sjs382 11y ago
  I am. I'm making heavy usage of keybase.io's kbpgp: https://keybase.io/kbpgp https://keybase.io/kbpgp
nickpsecurity 11y ago
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.
- sjs382 11y ago
  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.
  - nickpsecurity 11y ago
    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.
MichaelGG 11y ago
How do users verify keys are correct and not being sent to your server?
- sjs382 11y ago
  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/ https://www.passpack.com/blog/2008/03/host-proof-hosting/
  - MichaelGG 11y ago
    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?
    - ddoscampaign 11y ago
      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 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.
bramblerose 11y ago
> 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.
- sjs382 11y ago
  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.
  - MichaelGG 11y ago
    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.

tortilla 11y ago

Any screenshots?

sjs382 11y ago
There's an example form that I just threw up right here: http://sjstrutt.com/contact/ 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. :)
- davidcollantes 11y ago
  Submit with empty fields renders a 404 on the example.
  - sjs382 11y ago
    I've updated the thank you page. Sorry, I got the example up in a hurry :)
    - davidcollantes 11y ago
      Any reason why you are not validating the fields, to catch empty ones? Curious.
    - sjs382 11y ago
      @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.
  - bwblabs 11y ago
    That's called lean right? ;) It's only something worth solving if it hits the log files.
- sjs382 11y ago
  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.

daveloyall 11y ago

Looks like it uses this internally: https://github.com/keybase/kbpgp https://github.com/keybase/kbpgp Also, what's this? https://github.com/keybase/kbpgp/blob/master/LICENSE https://github.com/keybase/kbpgp/blob/master/LICENSE

sjs382 11y ago
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.

locacorten 11y ago

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).

sjs382 11y ago
It isn't important, but it's still a detail that some people who are security-conscious might care about.
- locacorten 11y ago
  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.
  - sjs382 11y ago
    You aren't paying for it. It's provided my my server provider, DigitalOcean.
    - locacorten 11y ago
      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.
  - MichaelGG 11y ago
    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.

philip1209 11y ago

I wonder if Keybase could start to provide apis/web packages for something like this.

bgibson 11y ago

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.

sjs382 11y ago
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.

sigjuice 11y ago

Nitpick: https://privateforms.com/faq https://privateforms.com/faq should say "All you need is internet access and a browser that supports JavaScript!" (No space between Java and Script)

sjs382 11y ago
Fixed! Thanks for the good eyes :)

sjs382 11y ago

In response to user feedback, I've implemented a 14-day trial period for all subscription plans.

aytekin 11y ago

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/ http://www.jotform.com/encrypted-forms/ It is free upto 100 responses/month.