初探苹果NEURLFilter API

在WWDC 2025上，苹果推出了一个有趣的新API——NEURLFilter，以应对我们之前讨论过的一个关键挑战：在保护用户免受网络威胁时，隐私与安全之间存在的固有冲突。这种冲突意味着安全过滤代码通常无法查看浏览器（应用）获取的URL，无法将其与可用的威胁情报进行比较并阻止恶意获取。通过直接向安全软件提供URL（一个好主意！），安全与隐私之间的冲突不必如此尖锐。

他们的技术演示很好地解释了该API的设计如何确保过滤器能够阻止恶意URL，同时不查看URL或客户端来源（例如IP地址）。

高层设计

从高层来看，该设计与Google SafeBrowsing或Defender的Network Protection大体相似——客户端使用一个包含"已知不良"URL的布隆过滤器来检查正在加载的URL是否已知为不良。如果过滤器未命中，则立即允许获取（布隆过滤器从不产生误报）。如果布隆过滤器指示命中，则向在线信誉服务发出请求以获取最终裁决。

隐私规则

现在，这里开始与其他实现细节不同：苹果的API将信誉请求发送到一个Oblivious HTTP中继，以向过滤供应商"隐藏"客户端的网络位置。使用同态加密执行"私有信息检索"，以确定URL是否在服务端阻止数据库中，而服务实际上无法"看到"该URL。

过滤请求由WebKit和苹果的原生URLSession API自动发送。未基于苹果HTTPS获取器构建的浏览器可以通过调用显式API来参与：

1

// 示例API调用

很巧妙，对吧？是的，非常酷。

它是否完美适用于每个产品？不。

局限性

系统设计中固有的一个事实是，苹果已经将其安全/隐私权衡融入了设计中，不允许覆盖。以下是一些可能给过滤供应商带来麻烦的局限性：

• 信誉检查无法再发现可能代表未阻止威胁的新URL，也无法使用查找来优先处理高流量URL的安全重新扫描。
• 似乎没有任何机制可以控制评估URL的哪些部分，从而无法控制诸如汇总之类的事情。
• 信誉服务不能有仅评估URL特定部分的规则（例如，如果某个活动在多个域上运行，且路径或查询中具有特定模式）。
• 似乎没有任何机制可以提交额外的上下文信息（例如重定向URL、IP地址），也没有任何方法在服务端以编程方式对其进行加权（以提供对抗隐藏的弹性）。
• 似乎没有任何机制允许非互联网操作（例如在主权云内），或确保信誉流量仅流经特定地理区域。
• 服务无法返回非二元裁决（例如"警告并允许覆盖"或"运行积极的客户端启发式"）。
• 当在苹果客户端发生阻止时，没有机制允许扩展参与反馈体验（例如"向服务报告误报"）。
• 没有明显的机制来确定哪个客户端设备执行了信誉检查（允许安全运营中心调查任何潜在的入侵）。
• 允许的最快布隆过滤器更新延迟为45分钟。

苹果的立场是"隐私是一项基本人权"，这是一个绝对崇高的立场。然而，反驳的观点是，对计算机用户隐私最根本的侵犯发生在钓鱼窃取其密码或部署窃取其本地文件的恶意软件时。工程全是关于权衡的，而在这个API中，苹果控制了权衡。

结论？

上述局限性是否意味着苹果的API"糟糕"？绝对不是。它是一个设计巧妙、功能强大的隐私保护API，适用于许多用例。如果我要在我孩子的Mac上安装家长控制软件，这绝对是我希望供应商使用的API。

您可以在NEURLFilterManager文档中了解更多关于苹果新API的信息。

-Eric

附言：我已经询问了Chromium团队是否计划调用此API。