Google 的 Privacy Sandbox 自提出以来就伴随着隐私与垄断的双重争议。作为回应，Brave 浏览器选择了一条截然不同的道路：不实施 Privacy Sandbox API，而是构建一套以拦截、分区与本地化为核心的替代方案。在 Android 与 iOS 移动平台，这一方案通过 WebView 深度集成、广告 API 拦截与设备内归因计算，实现了既保护用户隐私又不完全依赖 Google 生态的技术路径。本文将从工程角度拆解 Brave 在移动端的三大技术支柱，并分析其与 Privacy Sandbox 的本质差异。
为什么 Brave 拒绝 Privacy Sandbox？
Brave 公开批评 Privacy Sandbox 并非出于技术无能，而是基于对隐私与竞争格局的深刻判断。Privacy Sandbox 的核心组件 ——Topics API、Protected Audience API、Web Bundles 等 —— 虽在表面上减少了第三方 Cookie 的使用，却将广告匹配与用户兴趣推断的权力进一步集中到 Chrome 浏览器（亦即 Google）手中。例如，Topics API 会在本地推断用户的广告兴趣主题，并将这些主题共享给所有参与 Privacy Sandbox 的网站及其脚本。这意味着，用户的浏览历史仍然以 “主题” 形式暴露给大量第三方。
Brave 认为，真正的隐私保护不应以 “替换跟踪者” 为终点，而应以 “消除跟踪” 为目标。因此，Brave 的移动端方案建立在三个基本原则之上：1) 拦截所有第三方跟踪请求；2) 将每个网站的资源与状态严格隔离；3) 广告匹配与归因完全在设备内完成，数据不出设备。
技术支柱一：广告 API 拦截与请求过滤
在移动端，Brave 继承了桌面版的广告拦截引擎 adblock-rust。这是一个用 Rust 编写的高性能过滤引擎，支持 Easylist、EasyPrivacy 等主流规则集，并能实时更新。在 Android 平台上，Brave 通过修改 Chromium WebView 的网络栈，将 adblock-rust 嵌入请求流水线。所有 HTTP/HTTPS 请求在发出前都会经过过滤引擎的匹配，若命中规则则被直接阻断或重定向。
对于 Privacy Sandbox 相关的 API 请求（例如对 protectedaudience.googleapis.com 的调用），Brave 默认将其视为跟踪请求并拦截。这是因为 Brave 不信任 Google 控制的任何广告基础设施。在 iOS 端，由于系统限制只能使用 WKWebView，Brave 通过 内容拦截器（Content Blocker） 实现类似功能。iOS 的内容拦截器允许浏览器提供 JSON 格式的规则列表，系统会在网络请求阶段应用这些规则。Brave 将 adblock-rust 编译的规则转换为 iOS 支持的格式，从而在 WebKit 层面实现广告 API 拦截。
这种拦截策略带来的一个关键优势是减少资源消耗。Privacy Sandbox 的 Protected Audience API 需要在设备上进行实时广告拍卖，这会导致浏览器下载大量广告资源并执行复杂的 JavaScript 逻辑，显著消耗电量与内存。Brave 的拦截方式直接阻止了这些请求，避免了不必要的资源开销。
技术支柱二：网络状态分区（Network-State Partitioning）
拦截请求只是第一道防线。现代跟踪技术会利用浏览器缓存、HTTP/2 连接、Service Worker、IndexedDB 等多种 “网络状态” 进行跨站识别。Brave 在移动端实施了全面的网络状态分区，将每个顶级网站（eTLD+1）及其嵌入的第三方资源置于独立的隔离沙箱中。
具体而言，Brave 在 Android 上启用了 Chromium 中已存在但默认关闭的分区功能，并自行扩展了更多分区维度。这包括：
- 连接分区：不同站点的 HTTP/2、HTTP/3 连接完全隔离，防止通过连接 ID 进行跟踪。
- 缓存分区：图像、字体、CSS、脚本等资源的缓存按站点分割，避免通过缓存命中率推断用户跨站行为。
- 存储分区：Cookie、LocalStorage、SessionStorage、IndexedDB 等存储 API 均按来源分区，且 Brave 引入了独特的临时第三方存储策略：当用户离开某个网站后，该网站设置的第三方存储数据会被自动清除，即使在同一会话中。
在 iOS 端，Brave 利用 WKWebView 的 进程外模型（out-of-process model） 和 网站数据存储（Website Data Store） 配置来实现类似的分区效果。虽然 WebKit 的分区粒度不如 Chromium 灵活，但 Brave 通过组合使用 WKWebsiteDataStore 的不同策略，仍能实现关键状态（如 Cookie、缓存）的按站点隔离。
分区技术的最大价值在于其普适性：它不试图区分 “好” 的第三方与 “坏” 的第三方，而是将所有第三方资源视为潜在跟踪者并加以隔离。这避免了维护庞大过滤列表的复杂性，也减少了因误拦截导致的网站功能损坏。
技术支柱三：本地化广告匹配与归因计算
Brave 并非反对所有广告，而是反对基于跟踪的广告。其自家的 Brave Ads 平台展示了一种隐私优先的广告模式：广告匹配与归因完全在设备内进行。
在移动端，Brave 浏览器会定期从 Brave 服务器下载一个加密的广告目录，目录中包含广告创意、目标关键词及匿名化的活动 ID。目录下载后，匹配过程完全离线：浏览器根据本地上下文（如在 Brave Search 中的查询词、浏览页面的关键词）从目录中选择合适的广告展示。用户个人数据（浏览历史、位置、设备标识等）从未离开设备，也不会发送给 Brave 服务器或广告主。
归因（衡量广告效果）同样在本地完成。当用户点击广告时，浏览器会在本地记录点击事件与后续的转化行为（如安装应用、完成购买）。这些事件经过加密与匿名化处理后，会以聚合报告的形式延迟上传至 Brave 服务器。报告不包含任何个人标识符，且经过差分隐私处理，确保无法回溯到具体用户。
与 Privacy Sandbox 的 Attribution Reporting API 相比，Brave 的本地归因模型有两个显著区别：1) 数据最小化：Brave 不收集用户兴趣主题，只收集聚合后的效果数据；2) 无实时竞价：Brave Ads 采用固定费率购买，无需在设备上进行资源密集的实时拍卖，节省了计算资源。
移动端集成的工程挑战与适配
在 Android 平台，Brave 基于 Chromium 代码库构建，这使其能够深度修改 WebView 组件。Brave 工程师通过打补丁（patch）的方式移除了 Chromium 中与 Google 广告服务集成的代码模块，并注入自家的广告拦截与分区逻辑。构建时通过 target_os=android 参数生成移动端专属版本。
在 iOS 平台，由于 Apple 要求所有浏览器使用 WebKit 引擎，Brave 无法修改底层渲染与网络栈。因此，Brave 的隐私功能主要通过配置 WKWebView 的属性与使用系统提供的 API 实现。例如，通过 WKWebViewConfiguration 设置内容拦截器、自定义 Cookie 存储策略，以及利用 WKWebsiteDataStore 实现数据分区。虽然受限于系统，但 Brave 仍能在应用层实现大部分隐私保护功能。
性能、兼容性与未来挑战
Brave 的方案在隐私保护上表现优异，但也面临挑战。网络状态分区可能增加内存占用（每个站点需维护独立缓存），但 Brave 通过优化分区策略与定期清理未使用的数据来平衡。广告 API 拦截可能导致依赖这些 API 的网站功能异常，但此类网站在移动端本就稀少。
更大的挑战在于生态博弈。Google 正在逐步将 Privacy Sandbox 设为 Chrome 的默认配置，并可能通过 Android 系统权限或 Play Store 政策影响第三方浏览器的实现空间。Brave 需要持续维护其 Chromium 分支，确保与上游变更同步的同时，不被强制引入 Privacy Sandbox 组件。
结论：隐私优先的广告生态是否可行？
Brave 在移动端的实践证明，无需将用户兴趣数据共享给广告主，也能运行一个有效的广告系统。其技术三角 —— 拦截、分区、本地化 —— 提供了一种不同于 Privacy Sandbox 的替代范式。这一范式将隐私视为不可妥协的底线，而非可交换的商品。
对于开发者而言，Brave 的代码实现（尤其是对 Chromium 的补丁与 adblock-rust 的集成）是学习如何构建隐私增强型浏览器的重要参考。对于用户，Brave 提供了在移动端逃离 “跟踪经济” 的可行选择。尽管前路仍有竞争与技术的双重挑战，但 Brave 至少证明了一点：在隐私与广告之间，我们并非只能二选一。
资料来源
- Brave. “An overview of Google's Privacy Sandbox.” Brave Ads Learn. https://brave.com/brave-ads/learn/google-privacy-sandbox/ （对比 Brave Ads 与 Privacy Sandbox 的技术差异）
- Brave. “Partitioning network-state for privacy.” Brave Privacy Updates. https://brave.com/privacy-updates/14-partitioning-network-state/ （详解网络状态分区的实现与测试数据）