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 disc

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.