5 ms·

> 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 doe

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

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.