4 ms·

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 does

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