你是对的。鉴于您的目标，客户端加密可能没有多大意义。并不是说它一文不值，只是存在一些重大陷阱并且价值有限，因此您可能会更好地将时间花在其他措施上。关于这个主题的经典技术参考是Javascript Cryptography Considered Harmful。

如果您认为使用客户端加密可能有助于感知，即使它实际上并没有提高真正的安全性，我也不认为这是一个非常有希望的角度。普通用户不知道“客户端密码学”这个短语是什么意思，所以我认为他们不会将它与温暖的模糊感觉联系起来。

我认为您最好采取标准步骤来与用户建立信任并改进保护用户数据的方式。您是否已迁移到站点范围的 HTTPS？您是否有强有力的、对客户友好的隐私政策？您是否专注于为您的客户提供良好的服务并使他们对您的网站充满热情？

正如其他用户所提到的，围绕此的很多讨论将更多地属于 IT 安全的范畴。但是，我认为对此（或至少是讨论的开始）有一个 UX 观点，我将在下面尝试详细说明。

您已经在问题本身中提到了答案：

客户端加密可能会给人一种控制感

正如您所提到的，客户端和服务器端加密在安全性方面都不是万无一失的，所以它们之间没有什么可以选择的，对吧？

嗯，有 - 这是关于感知的。如果您的用户认为他们的数据正在以安全的方式得到处理，那么无论是否确实如此，他们都可能会更高兴。

诚然，重要的是不要对您的用户撒谎，但由于大多数应用程序中只有少数用户可能会关心，您可以在不会进入的地方讨论您的安全解决方案的基本细节不感兴趣的用户的方式。

鉴于此，我建议的解决方案是执行客户端加密以让您的用户有一种控制感，然后逐步披露您的安全机制、其细节以及它的安全程度，对于那些做关心。

编辑：我知道这个职位可能会产生道德影响，具体取决于您认为用户需要看到的内容。然而，从冷静的角度来看，感知为王。

您可以为浏览器编写离线模式客户端，例如用于 Google Chrome 的 Google Mail 离线客户端（它是在瘦客户端中运行的胖客户端！）。

这样JS代码：

• 在浏览器中运行，使用通常的沙盒（不能与用户文件混淆等）
• 但它只下载一次，不能按用户/每个连接更改

为了确保每个用户都获得相同的包，它的指纹需要在公共存储库中发布，最好在许多站点上复制，并在下载后、安装前自动检查。

警告：这只是一个想法的暗示。我没有研究过“离线阅读器”安全模型。

注意：Firefox 扩展可以完全访问浏览器中的所有内容（它们不是沙盒），因此它们不适合在这里，因为它们暗示了用户的完全信任，这不是给定的（而不是有限的“我相信你这些信息，我相信您会遵守您的隐私政策”）。

在客户端使用 JavaScript 进行加密具有开源安全性的优势 - 您不会隐藏某些 ROT-13“加密”方案，因此用户会更加信任您。如果有人闯入您的服务器并用恶意代码替换所说的 JavaScript，这也成立。

大多数用户不会阅读 JavaScript 或将其与缓存版本进行比较，如果存在违规行为，一些用户的机密会被盗。但你不太可能成为过去五年在不知不觉中泄露所有用户秘密的公司。