网页内容分类过滤

自互联网诞生之初，用户和管理员就试图控制从互联网到本地设备的信息流。实现网络过滤器的方法多种多样，组织可能希望达成的目标也各不相同：

阻止恶意网站
阻止广告或跟踪器
根据网站提供的内容类别阻止响应

本文探讨最后一种：基于类别的内容阻止。

客户目标

客户目标通常很简单：让管理员能够控制设备上可以下载和查看的内容类型。这通常作为组织可接受使用政策（AUP）的执行机制。

AUP通常定义允许用户交互的内容类型。例如，学校可能禁止学生查看色情内容以及与酒精、烟草、赌博、枪支、黑客或其他犯罪活动相关的网站。同样，公司可能希望禁止员工在数据和社交媒体网站上花费时间，或使用合法但未经批准的工具共享文件、召开会议或与人工智能交互。

看似简单实则不可能

目标的简单性掩盖了实现它的不可能性。在当今的网络上，类别过滤本质上无法完美实现，原因如下：

新网站每天都在不断出现
任何网站提供的内容都可能随时更改
内容类别无限多（没有真正的标准分类法）
网站类别的决定本质上是主观的
许多网站托管跨多个类别的内容，有些网站托管几乎每个类别的内容
自我标签方案（如ICRA和PICS）都未能被采纳

作为工程师，虽然只处理可解决的问题很好，但在生活中，有许多棘手的问题客户愿意购买不完美的尽力而为解决方案。

网络内容分类就是其中之一，由于网站和类别不断变化，内容过滤通常以订阅方式出售，而不是一次性收费。当今大多数公司都喜欢经常性收入流。

过滤方法

第一个挑战是弄清楚如何以及在何处阻止内容。有许多方法；微软的各种网页内容过滤产品和功能展示了其中三种：

浏览器集成 – Defender WCF-atop-Edge 或 Edge 原生 WCF（仅适用于特定 M365 许可证持有者）
设备上网络过滤 – Defender WCF-atop-Network-Protection
远程代理或 VPN – Microsoft Entra Global Secure Access

每种实现方法都有其优缺点：

支持的浏览器：是否适用于任何浏览器？仅适用于一小部分列表？仅适用于特定浏览器？
性能：是否会减慢浏览速度？因为产品可能对数十亿个 URL 进行分类，通常无法将映射存储在客户端设备上。
用户体验：可以显示哪种阻止通知？是否在上下文中显示？
功能：是仅阻止框架导航（例如 HTML），还是可以阻止任何子资源（图像、视频、下载等）？阻止是针对当前用户还是整个设备？

分类

选择过滤方法后，开发人员必须选择分类信息的来源。已经不断爬取和监控网络的公司（例如构建 Bing 或 Google 等搜索引擎）可能会自己执行分类，但大多数供应商从专门从事分类的分类供应商（如 NetStar 或 Cyren）获取数据。

然而，暴露分类供应商的整个分类法可能会有问题——如果你将产品提供过于紧密地绑定到第三方分类，分类供应商所做的任何分类法更改都可能成为你的产品及其客户的重大更改。因此，另一种方式很诱人：询问客户他们期望的类别，然后将分类供应商的任何分类法映射到客户可见的类别。

例如，Microsoft Defender WCF 就采用了这种方法，但这可能会导致意外。例如，Defender WCF 将 archive.org 分类为非法软件类别，因为我们的数据供应商的远程代理类别被映射到那里。但对浏览器用户来说，这种不透明的选择可能非常令人困惑——虽然 archive.org 几乎肯定包含非法内容（它实际上是整个网络的延迟代理），但这不是正常人在被问及该网站时首先想到的类别。

最终，实施网页内容过滤的企业必须预期会有他们不同意的分类，或者他们同意其类别但希望允许的网站（例如，因为他们在某个特定的社交网络上运行广告）。管理员应定义一个流程，用户可以通过该流程请求豁免或重新分类，然后管理员评估请求是否合理。在 Defender 中，允许自定义网络指示器将覆盖站点的任何 WCF 类别阻止。

如果你的分类方法需要进行 Web 服务请求来查找内容类别，你通常希望与内容请求并行执行以提高性能。但是，如果资源在类别信息之前返回会发生什么？

即使只显示几秒钟要被阻止的内容（例如色情网站）也可能是不可接受的。为了解决 Defender WCF 的这一问题，Edge 目前在 about:flags 页面上提供以下标志：

很自然地认为检查所有子资源的类别优于仅检查页面/框架导航的类别：毕竟，很容易想象规避，例如，通过在某个无害位置建立一个简单的网页，其中包含大量直接指向色情视频内容的 <video> 元素，来规避成人内容过滤器。仅阻止顶级导航的过滤器不会阻止视频。

然而，相反的问题也可能发生。例如，一个 IT 部门最近试图阻止一大片生成式 AI 网站，以确保公司数据不会与未经批准的供应商共享。然而，该公司还将其福利计划的履行外包给一个经批准的第三方供应商。该福利网站依赖一个由最近转向生成式 AI 的公司提供支持的帮助聊天机器人。访问福利网站的员工现在看到来自网页内容过滤的阻止通知，原因是支持帮助聊天机器人的 .js 文件。员工自然感到困惑——他们正在使用 HR 告诉他们使用的网站，却收到阻止通知，暗示他们不应该使用 AI。糟糕。

通常，网页内容过滤不被视为安全功能，即使它可能通过减少用户可以访问的网站数量来减少组织的攻击面。特别令人感兴趣的是新站点类别——如果一个组织阻止用户访问所有比，比如说，30 天新，并且尚未分类到其他类别的站点，他们不仅减少了新站点逃避阻止策略的机会（例如，一个尚未被供应商分类的新色情网站），这也提供了一种防止鱼叉式网络钓鱼攻击的保护形式。

不幸的是，提供新站点类别的健壮实现并不像听起来那么容易：对于数据供应商来说，要对一个站点进行分类，他们必须知道其域名存在。根据供应商的数据收集实践，这种发现可能需要相当长的时间。这是因为互联网的设计方式：新域名上线时没有“公告”。相反，DNS 服务器只是获得一个新记录，将站点的主机名绑定到其托管 IP 地址，并且仅当客户端请求时才会返回该新记录。

简单地将所有未分类的站点视为“新”站点有其自身的问题（如果站点在公司的内部网络上，数据供应商永远无法访问它怎么办？）。相反，供应商可能通过监控证书透明度日志、爬取链接到新域的网络内容、观察广泛部署的客户端监控软件（“被动 DNS”）的 DNS 解析，或通过与浏览器集成（例如作为浏览器扩展）来了解新站点，以便在用户导航到它们时发现新站点。在发现域名后，供应商可以尝试加载它并使用其分类引擎确定站点应属的类别。

-Eric

PS：在 BlueSky 上，Nathan McNulty 比较了 Defender WCF 的类别列表与 GSA 的列表。