
Show HN: Private Forms: PGP-Encrypted Webforms for Privacy-Conscious Receipients - sjs382
https://privateforms.com
======
sjs382
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)

~~~
bramblerose
> 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
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
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.

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

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

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

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

------
sigjuice
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
Fixed! Thanks for the good eyes :)

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

~~~
bwblabs
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](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;
                }
            );
        });

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

~~~
MichaelGG
There is no such thing as usable encryption without integrity
(authentication). Client side crypto here changes rather little.

------
tortilla
Any screenshots?

~~~
sjs382
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
Submit with empty fields renders a 404 on the example.

~~~
sjs382
I've updated the thank you page. Sorry, I got the example up in a hurry :)

~~~
sjs382
@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.

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

