它更好但并不完美。

虽然（目前）不可能获取给定哈希的 URL，但当然每个 URL 都具有相同的哈希。

因此，不可能查看用户浏览的所有 URL，但很有可能获得其中的大部分。

虽然不可能看到用户 A 访问 HASH1 并得出结论 HASH1 表示fancyDomainBelongingToUserA-NoOneElseVisits.com，但例如可以只计算哈希值CheatOnMyWife.fancytld，然后查看哪些用户访问了该站点。

我不认为这是保护用户隐私。

此外，仅匹配访问许多类似域的用户可能会很有启发性。

我认为您想保护用户的隐私很好，但是您正在构建的内容似乎与保护隐私相反，因此我认为不可能通过简单的设置来完成（例如，客户端以任何形式发送 url ，直接到您的后端服务）。

正如其他人所指出的，使用 sha1 进行散列是一个很好的第一步，但它只能实现隐私，防止人类冒着快速浏览数据库的风险。它不会为您提供针对旨在分析数据库内容的算法的太多隐私。

你泄露的不仅仅是访问的 url：如果你正在做实时检查，用户还会告诉你他什么时候在线并查看给定的 url。

其他一些人提出了解决隐私问题的解决方案。虽然他们都比什么都不做要好，但他们并没有解决问题。例如，Google 只发送 32 位哈希的解决方案看起来不错，但它仍然只将所有现有 url 映射到具有 40 亿个槽的哈希表。其中一些插槽可能包含大量条目，但由于并非所有 url 都同样可能被访问（例如，facebook url 比某些小学的主页更有可能被访问）并且单个域的 url 将很可能在 40 亿个可用插槽上相当均匀地散列，它仍然很容易猜到，给定一组完整的 url，它们散列到相同的 32 位前缀，实际上访问了哪个 url（尤其是对于 google，

此类攻击涉及某人构建他感兴趣的 URL 的彩虹表。您可以通过以下方式使其变得更加困难

1. 使用密码散列函数而不是 sha1，这需要很长时间来计算散列 - 但这意味着您的浏览器插件似乎没有响应。
2. 给你的哈希加盐。显然，您不能给每个用户自己的盐，或者不同用户提供的相同 url 的所有哈希值都是唯一的，这很可能使您的应用程序毫无意义。但是您的用户群增长得越大，需要相同盐值的用户就越少。您仍然没有保护用户隐私，但是您更难以计算彩虹表以准确找出访问了哪些网址，如果有人这样做是为了特定用户的盐，只有所有其他用户的隐私共享他的盐受到损害。

但是，如果攻击者对整组散列 URL 不感兴趣，而只想回答非常具体的问题（例如，哪些用户访问了属于给定域中的域的 URL），这仍然没有任何帮助。黑名单”？）因为这样的查询只涉及一个简短的列表（可能几十到几十万个 url，取决于黑名单的大小），在很短的时间内对它们中的每一个进行哈希处理是微不足道的，不不管你用什么对策来减慢它。

比这更糟糕的是，因为许多网站只有几个共同的入口点，最有可能的只是域，后面跟着一个空路径。其他经常访问的路径是登录页面、个人资料页面等，因此您需要散列的 url 数量以确定是否有人访问过特定域很可能非常少。如果攻击者这样做，他会错过使用网站深层链接的用户，但他会抓住其中的大部分。

更糟糕的是：如果攻击者设法从用户​​提供的哈希中找到一个完整的 url，他可能很容易获得该用户大部分浏览会话的所有 url。如何？好吧，既然他有一个 url，他可以用他自己的自定义爬虫取消引用它，查看文档中的所有链接，对它们进行哈希处理并在您的数据库中查找它们。然后他对这些链接做同样的事情，依此类推。

所以你可以做一些事情让它变得更难，但我认为没有办法让用户基本上信任你的浏览历史。我能看到的唯一方法是构建一个不完全受您控制的分布式系统并使用它来收集 url，例如一种混合器网络。另一种情况可能是让客户端下载大部分数据库内容，从而隐藏他们真正感兴趣的 url，并仅以大数据包的形式为您的数据库提供新内容，这至少会隐藏用户浏览的时间部分.

简短的回答。

虽然您表示您担心最终用户的隐私，但不清楚您打算“保护”他们免受谁的侵害以及出于什么原因？

• 如果您的应用程序的核心功能本质上是从客户端收集用户数据，将其发送到服务器并交付结果，那么您作为该数据的接收者将始终知道该数据是什么。
• 如果您的目标是保护从客户端传输到服务器的数据不被第三方窃取，那么可以设计一种加密方案来保护传输。但这绝对是保护用户数据所能做的最好的事情。

长答案。

首先你这样说：

我正在做一个涉及浏览器插件和后端服务的小型项目。该服务非常简单：给它一个 URL，它会检查该 URL 是否存在于数据库中。如果找到 URL，还会返回一些附加信息。

然后你这样说：

浏览器插件将用户打开的任何 URL 转发到服务并检查响应。现在，共享您正在浏览的每个 URL 当然是一个很大的禁忌。

您描述的方案的问题以及您对隐私的担忧是，您的应用程序的核心、固有行为是共享传统上被认为是私有的信息。因此，归根结底，您打算为谁、出于什么原因、出于什么原因保护什么级别的“隐私”？

如果有人同意使用你的应用程序——对应用程序的功能和共享的信息有一些基本的、初步的了解——他们很可能知道你的后端服务器会准确地知道他们浏览的内容。哦，当然，您可以设置任何精心设计的散列方案来“屏蔽”URL，但最终您的后端服务器将知道最终用户的数据。即使你确信这些数据对你来说是未知的，它仍然不会阻止你知道数据是什么的看法；老实说，我无法设想一种方案，您可以提供此服务，并且您不知道正在浏览哪些 URL。

如果您担心用户数据在传输到某种潜在的第 3 方时泄漏，那么也许您可以想出一些加密方案来保护正在传输的数据。对我来说，这是可行的。

但是，如果您的总体愿望是收集某种类型的私人数据来分析它，然后提供最终结果，那么您和您的系统的整体概念不知何故不了解该数据的细节是有缺陷的。您可以控制这样的流程的后端，并且无论您喜欢与否，您都可以完全访问数据。

您存储（部分）URL 哈希的建议是减轻对隐私影响的既定方法。虽然这使得回答“你去过哪些页面？”变得更加困难。如果您知道要查找的确切页面显然仍然是微不足道的，因为哈希对于每个 URL 实际上都是唯一的。

您所描述的正是谷歌安全浏览服务必须解决的问题。Chrome 和其他应用程序使用此服务在浏览时根据 Google 的危险网站列表检查可疑 URL - 仍然需要确保一定程度的隐私。

Google 在Google Chrome 隐私白皮书中概述了他们的方法：

在 Chrome 中启用安全浏览后，Chrome 会定期与 Google 的服务器联系，以下载最新的不安全网站的安全浏览列表，包括网络钓鱼、社交工程和恶意软件网站，以及导致垃圾软件的网站。此列表的最新副本存储在您的系统本地。Chrome 会根据此本地列表检查您访问的每个站点或下载的文件的 URL。如果您导航到出现在列表中的 URL，Chrome 会向 Google 发送部分 URL 指纹（该 URL 的 SHA-256 哈希的前 32 位），以验证该 URL 确实是危险的。当网站请求具有潜在危险的权限时，Chrome 还会发送部分 URL 指纹，以便 Google 可以在该网站存在恶意时保护您。Google 无法根据此信息确定实际 URL。

（强调我自己的）

请注意，如果您的服务可以接受一些误报，您可以只存储一小部分散列，以提高查找速度和合理的可否认性。