NFTstorage有1000万个NFT被中心化网络的谷歌阻止，这就是互联网需要使用去中心化IPFS升级的原因；我们有解决方案

网关和看门人：Google 的错误如何影响 web3

Ipfs网关谷歌网络2

在 web2 世界中操作 IPFS HTTP 网关

大卫崔2022 年 4 月 29 日

NFT.Storage 在 3 月初推出了我们的 IPFS HTTP 网关，这在很大程度上取得了成功——它目前每天提供 25 到 3000 万次 NFT 读取，无需用户安装任何专业软件，支持数十个 NFT 市场和项目。

然而，它并非一帆风顺。这篇文章讨论了 NFT.Storage 团队自推出以来由于当今网络“看门人”所犯的错误而面临的痛点。这包括谷歌浏览器安全浏览在两个单独的实例上造成的中断，其中误报导致他们标记整个网关域，以有效地整个网络浏览群体每次 4 多个小时（阻止用户访问大约 5,000,000 个 NFT 请求实例），以及安全供应商标记域的较小实例，从而给来自不可预测的地方的用户带来问题。我们分享我们的经验，以在 IPFS 生态系统和控制当今 Web 体验的强大实体（如浏览器、安全供应商和大型网站）之间展开对话。

IPFS HTTP 网关：入门

IPFS HTTP 网关是将当前网络连接到更安全、高性能和去中心化版本的关键基础设施。它们允许未运行自己的 IPFS 节点的用户通过标准 HTTP 从公共 IPFS 网络访问数据，这意味着 Web 浏览器和常用工具和应用程序可以轻松读取其 IPFS 内容 ID (CID) 正在广播到公共网络的数据. 今天有许多公共网关作为公共服务运行，更多作为付费服务运行，并且可能还会有更多。

用户通过在其 HTTP 请求中包含 CID 来从 IPFS HTTP 网关请求内容。由于 CID 是特定数据的散列，如果数据被广播到网关并可由网关访问，那么无论网关位于何处，网关都可以从网络获取该特定数据。

它并不完美——例如，网关仍然是集中式基础设施，这意味着它们将不可避免地面临中断。但是，由于仍然通过其唯一的 CID 请求内容，因此您最终不仅可以从任何网关请求给定内容，而且还可以获得其他好处，例如能够访问给定内容的缓存副本。只缓存一次。网关是Web2.5 世界中可行的去中心化解决方案。

网关和恶意内容

只要网络存在，网络上就存在恶意内容，不良行为者希望利用不知情（或有时是知情）的用户。对于 IPFS 网关，考虑到 CID 的性质，这个问题得到了非常优雅的处理——如果网关知道阻止给定的 CID，它就知道永远不会提供内容，无论是谁请求它或它可能位于 IPFS 网络的哪个位置。它类似于某些病毒扫描软件在本地使用的技术，但应用于网络上的内容。

网关使用的一种方法是在“Bad Bits”拒绝列表中报告恶意 CID，并制作一个可以与网关安全集成的公开可用列表，以便网关可以阻止对这些 CID 的请求。此外，网关可以使用网关 URL 的子域中的 CID 来提供内容。这允许网关下游人员（如 Web 服务器、安全提供商和浏览器）执行的任何域级阻止，都可以隔离到与不良 CID 关联的特定子域。这使得在不阻止整个网关的情况下阻止隔离的 CID 是安全的，确保整个网关服务不会被单个不良行为者上传的恶意内容中断。

从互联网上删除

NFT.Storage在 3 月初推出了我们的网关。采用速度迅速加快，到第二周，每周的请求已经达到 2500 万。铸造 Solana Metaplex NFT（需要 HTTP URL）（如 Magic Eden）的人们开始使用包含相关 NFT 内容的 CID 的 nftstorage.link URL。一些最新数据包括上周超过 1.55 亿个超过 1000 TB 的请求和超过 70% 的缓存命中率。

我们还很快从 web2 世界中发现了超大的锤子，尽管由于他们的错误，它们仍然能够使整个业务部门离线。尽管为网关采取了积极的安全措施，但我们今天的网络结构导致仅谷歌就为我们、我们的数十名用户和他们的约 10,000,000 个最终用户请求造成了两次重大服务中断，以及一场持续的与较小的安全供应商打地鼠。

事件 1：Google 安全浏览

2022 年 3 月 29 日，开始有用户报告称，通过任何主要网络浏览器通过 nftstorage.link 访问的所有内容都会导致 Google 安全浏览警告。但是，在所有报告的情况下，内容都是无害的——NFT JSON、PNG、JPEG 等。

NFT.Storage 用户尝试访问 NFT 元数据 JSON 文件的屏幕截图。

经过一番激烈的搜索（以及来自随机帮助网站的指导），我们了解到我们必须登录 Google Search Console 以了解更多关于我们的域被阻止的原因。控制台清楚地表明特定 CID 是罪魁祸首，我们验证了该内容是网络钓鱼表单。然而，即使在立即阻止此 CID 之后，我们所能做的只是“请求审查”，这可能需要长达 72 小时。这是非常不透明的，没有请求跟踪器，甚至没有电子邮件告诉我们我们的请求正在审核中。

您只能在 Google Search Console 中清除误报报告，体验不符合用户急于清除其域的需求。

很明显，许多浏览器和服务都使用了这个列表——不仅仅是 Chrome，还有 Firefox、Twitter、Phantom Wallet 等等！因此，鉴于在此列表中实际上导致 nftstorage.link 完全中断，我们不能等待 72 小时。我们尝试了其他方法来重新上线，例如让 nftstorage.link 直接 CNAME 到 dweb.link 公共网关，但这不起作用，因为 nftstorage.link 在域级别被阻止。

我们的团队和 IPFS 生态系统的其他成员尝试通过我们共同认识的每个 Google 人员进行反向通道，但这发生在一个相当不方便的时间 - 太平洋时间深夜和欧洲工作日开始之前。几个小时后，我们终于间接接触到了负责团队。他们将我们从黑名单中删除，并且我们收到了确认我们的 Google Search Console 请求已被接受的电子邮件。我们的反向渠道联系人告诉我们，团队承诺永远不会阻止整个域向前发展，而只会阻止与恶意内容相对应的相关子域，我们认为这是一个积极的结果。

与此同时，估计有大约 5,000,000 个请求被网关阻止。这对于 Solana 的人们来说尤其令人担忧，他们拥有使用 nftstorage.link 铸造的 NFT，并且他们无法在钱包中访问它们，从而导致害怕拉扯地毯。

后来我们了解到，我们并不是唯一遭受这个确切问题的人——谷歌在没有及时或透明的追索权的情况下不透明地阻止了他们的域。此 Hacker News 线程包含有关该主题的各种想法。这主要是对一个实体在没有选择的情况下对网络拥有如此大的权力的前提下的愤怒，但结论通常是个人无能为力。

事件 2：与安全供应商发生冲突

自此最初事件以来，还有其他一些孤立的报告称，用户被阻止通过网关访问无害的内容。有时，很容易找出原因 - 例如，Avast Antivirus 标记了所有 nftstorage.link 域。在其他情况下，它更加不透明，例如返回 SSL HTTP 错误而没有任何进一步的解释。有时，行为有多种，例如基于子域和基于路径的 CID 会给出不同的结果。总体而言，我们收到了由 ISP、防病毒软件（但在使用相同软件的用户之间不一致，如 Windows Defender）、VPN 等引起的孤立问题的报告。

更麻烦的是，有时用户会通过其他工具遇到这些错误，这意味着调试起来很困难。例如，当用户的钱包由于这些问题而无法显示他们的 NFT 时，我们不会收到明确的错误消息。事实上，有时根本原因甚至不是 nftstorage.link - 我们的团队花了一个多星期的时间来调试 dweb.link 公共网关的错误。

为了尝试隔离造成这些问题的各个软件供应商，我们查看了Virus Total等网站，告诉我们哪些安全供应商标记了 nftstorage.link 或 ipfs.nftstorage.link（令人困惑的是，不同的供应商子集标记了每个这些域是可疑的）并与这些团队联系，让他们知道存在误报。像 Avast 这样的人反应非常迅速，并立即解决了这些问题。其他人，如 Webroot，在没有任何解释或继续对话的简单机会的情况下推后。还有一些人甚至在多次跟进后也没有回应。最终，由于不解决我们的请求，这些软件供应商最终会通过阻止所有具有网关域的 URL 来增加误报率。

Virus Total 可以方便地识别哪些安全供应商标记了 nftstorage.link，尽管并非所有这些供应商都愿意进行讨论。

一项观察是，这些供应商可能使用 Google 的列表来通知他们的列表（解释为什么其中一些列表将 nftstorage.link 标记为可疑）。反过来，ISP、VPN 和其他人使用这些安全供应商的列表，但存在一些异步性（例如，ISP Swisscom 已阻止所有 nftstorage.link 域，但当我们要求他们从拒绝名单中删除该域时，他们遵守了，说它已从他们使用的第 3 方列表中删除）。在每种情况下，整个依赖链都非常不透明。

目前，此类报告已经平息，尽管我们绝对欢迎任何安全供应商了解他们如何处理 nftstorage.link 和其他网关，以确保他们不会陷入这个误报网络。

事件 3：谷歌……再次

2022 年 4 月 21 日，谷歌浏览器安全浏览再次封锁了整个 nftstorage.link 域，导致与以前一样的所有下游影响。我们对此感到震惊和担忧是可以理解的，因为他们向我们保证，整个域将永远不会再被封锁。

这一次，我们很难通过反向渠道与相关团队取得联系。我们遵循与以前相同的协议，但问题持续了几个小时，因此我们公开发布了有关这些问题的推文。

尽管标记的内容与一个 CID 子域隔离，但整个 (nftstorage .link) 网关域当前被@googlechrome阻止。@Google之前向我们保证不会发生这种情况。我们正在努力解决这个问题。#中心化# Web2 (1/2)

— NFT.Storage (@nft_storage) 2022 年 4 月 21 日

当第二轮问题没有及时解决时，我们让我们的用户知道并打电话给谷歌。

过了一会儿，问题突然自行解决了——减去带有特定恶意 CID 的 URL，但网关被解锁了。我们松了一口气，但奇怪的是，这次我们没有收到来自 Google Search Console 的通知，表明我们的请求已被接受。

第二天，我们的一位 Google 联系人告诉我们，相关团队承认他们输入了错误的正则表达式语句。我们以前都去过那里，但是对于这样一个强大的实体仍然明显缺乏关心（为什么没有更好的测试？），以及令人震惊的缺乏透明度（他们为什么不让我们知道？）。

给网络运营商的建议

在仅仅一个多月的运营中，每天就有数百万次对 nftstorage.link 的请求。在 IPFS 节点在浏览器、移动设备和其他地方得到更广泛的采用之前，看到成百上千个用于不同目的的网关也就不足为奇了。在我们的去中心化达到足够的临界质量之前，还有一段路要走，以确保这些问题不会再次发生在普通网络用户身上。目前，我们详细介绍了一些建议和对话主题，以理想地为所涉及的各个群体启动对话。

网关提供商

如果您是网关提供商，我们建议实施我们上面概述的安全措施，即使用Bad Bits Denylist自动阻止来自您的网关的加密 CID，并确保安全提供商可以轻松地通过路由所有请求使用基于子域的CID 请求。

否则，如果您的网关应该用于特定内容，请限制内容以减少通过您的网关提供的恶意内容的表面积。可能最相关：如果网站托管没有用，请阻止text/html响应类型——它将删除在您的网关上托管网络钓鱼静态 HTML 页面的能力。您还可以考虑阻止 Javascript 内容、cookie、Web API 访问等。

如果您想托管静态 HTML 但又不想允许 Javascript 或 cookie，则还可能有用的是返回带有 HTTP 响应的附加标头（尽管这不能防止大多数基本的网络钓鱼活动）：

• Clear-Site-Data: "cookies", "storage"：只清除cookies，保留“缓存”
• Content-Security-Policy:禁用 JS 和各种安全功能的既定方法
• Permissions-Policy（以前命名 Feature-Policy）：禁用各种 API 和行为的另一种方法，尽管 Google 的 WIP

您还可以尝试将您的网关添加到Public Suffix List中。公共后缀列表是“一项跨供应商倡议，旨在提供准确的域名后缀列表。” 这使得安全供应商不太可能阻止您的整个域，并在误报的情况下提供一些容易指出的东西。我们还没有成功添加 nftstorage.link ( request )，但是 dweb.link之前被接受了。

安全供应商和浏览器

如果您是标记恶意内容的浏览器或安全供应商，我们建议您对域的分类方式保持透明，最好包括 IPFS 网关分类。这与这些供应商中有多少已经处理点对点文件共享网站或发布用户和开发人员内容的网站应该没有太大区别，它们面临一些相同的基本问题。事实上，根据我们的经验，具有代表这些类型网站的类别的安全供应商能够最快地解决我们对 nftstorage.link 的误报请求。

此外，如果您是使用第三方阻止列表（如 Google Chrome）的供应商或浏览器，我们建议您在列表告诉您阻止整个域时要小心。通过对提供用户上传内容的网站进行自己的分类，当第 3 方列表告诉您阻止整个域时，您可以检查自己的列表，并且您可以防止这些第 3 方列表的力量错误地取消整个服务在检查。

在任何一种情况下，对误报进行宣传良好、透明且及时的审查过程可能是您可以做的最好的事情，以使网络受益。即使有最好的意图，错误也几乎肯定会发生。认真对待你的权力和相关责任，将带来更健康的网络。

去中心化看门人

理想情况下，网络的最终状态涉及比今天更深层次的去中心化。IPFS 等技术降低了看门人破坏网络关键部分的能力，无论他们的意图如何。实际上，实现这一目标需要时间和精力，尽管随着越来越多的人构建和采用 web3 解决方案，事情正朝着正确的方向发展。同时，我们希望 IPFS HTTP 网关的案例显示出一条有希望的途径，以进一步分散 Web 基础设施，并且互联网看门人需要改进以实现这一进展。

相关：