Privacy Badger 禁用站点功能的技术演进与一致性设计

在Privacy Badger浏览器扩展的开发过程中，团队发现了一个关于禁用站点功能的重要技术差异。本文将深入分析这一问题的技术背景、解决方案以及对用户体验的影响。

问题背景

Privacy Badger从MV2架构升级到MV3架构时，在禁用站点功能上出现了行为差异。在MV3版本中，当用户禁用某个站点（如example.com）时，系统会自动同时禁用该站点的所有子域名（如*.example.com）。这是由于MV3使用了DNR（Declarative Net Request）API的"allowAllRequests"规则特性。

技术实现差异

MV2版本原本支持更细粒度的控制，允许用户单独禁用主域名而不影响子域名。这种差异源于两种架构的不同实现方式：

1. MV2版本使用传统的webRequest API，可以精确匹配域名模式
2. MV3版本使用DNR API，其requestDomains规则会自然包含子域名

一致性设计决策

开发团队经过评估后做出了重要决策：统一两个版本的行为，都采用包含子域名的禁用方式。这一决定基于以下考虑：

1. 用户体验一致性：确保用户在MV2和MV3版本中获得相同的功能体验
2. 简化操作：大多数情况下用户确实希望同时禁用主站和子站
3. 技术可行性：MV3的架构限制使得细粒度控制实现成本过高

技术实现调整

为实现这一目标，团队进行了以下代码调整：

1. 修改MV2版本的匹配逻辑，使其行为与MV3一致
2. 更新用户界面，移除域名输入框中的通配符提示
3. 改进输入验证，禁止用户输入通配符
4. 自动清理现有配置中的通配符条目

对用户的影响

这一变更对普通用户的影响较小，因为：

1. 大多数用户禁用站点时本就期望包含子站点
2. 操作界面更加简洁，减少了混淆可能性
3. 跨浏览器体验更加一致

技术细节

在底层实现上，当用户禁用example.com时，系统会创建两个等效条目：

• example.com
• *.example.com

这种实现确保了在各种情况下的兼容性和一致性。

总结

Privacy Badger团队通过这次架构升级，不仅解决了技术兼容性问题，还优化了产品设计，使禁用站点功能更加符合用户直觉。这一案例展示了优秀开源项目如何在技术演进中保持用户体验的一致性。