设备端个性化 - 提供更完善的隐私保护，提供个性化体验

我们打算在 Android 开源项目 (AOSP) 中实现设备端个性化 (ODP)。这篇技术说明文档介绍了 ODP 背后的动机、指导 ODP 开发工作的设计原则、“通过机密性实现隐私保护”模型，以及 ODP 如何帮助确保实现可验证的隐私保护体验。

我们计划通过简化数据访问模型并确保所有离开安全边界的用户数据在每个（用户、采用者、model_instance）级别（在下文中，有时仅指用户级别）具有差分隐私性来实现这一点。

与来自最终用户设备的潜在最终用户数据出站相关的所有代码都是开源的，并可由外部实体验证。在我们提案的早期阶段，为构建一个有机会推动实现设备端个性化的平台，我们希望激发用户的兴趣并收集反馈。我们诚邀隐私保护专家、数据分析师和安全从业者等利益相关方参与进来。

视觉

设备端个性化旨在保护最终用户的信息，不让用户未互动过的企业获取用户的确切信息。企业可以继续为最终用户定制产品和服务（例如，使用经过适当匿名化和差分隐私处理的机器学习模型），但他们无法查看为最终用户进行的确切定制（不仅取决于企业主生成的定制规则，还取决于最终用户的个体偏好），除非企业与最终用户存在直接互动。如果企业搭建了任何机器学习模型或进行了任何统计分析，ODP 将设法确保使用适当的差分隐私机制对这些模型和分析进行适当的匿名化处理。

目前，我们计划以多个里程碑来探索 ODP，涵盖以下特征和功能。我们还邀请有意向的各方提出有建设性的建议，将更多特征或工作流纳入进来，以做进一步探索：

1. 一种沙盒化环境，其中包含并执行所有业务逻辑，其允许大量最终用户信号进入沙盒，同时限制输出。

2. 进行了端到端加密的数据存储区，适用于：

   1. 用户控制项和其他用户相关数据。这些信息可以由最终用户提供，也可以由企业收集和推理，也包含存留时间 (TTL) 控制项、擦除政策、隐私保护政策等。
   2. 企业配置。ODP 提供用于压缩或混淆处理这些数据的算法。
   3. 企业处理结果。这些结果可能是：
      1. 在后续几轮处理中用作输入，
      2. 根据适当的差分隐私机制添加噪声，并上传到符合条件的端点。
      3. 采用适当的中央差分隐私机制，使用可信上传流上传到运行开源工作负载的可信执行环境 (TEE)
      4. 向最终用户显示。

3. API 旨在：

   1. 批量或增量更新 2(a)。
   2. 定期（批量或增量）更新 2(b)。
   3. 在可信聚合环境中采用适当的噪声机制上传 2(c)。在接下来的处理轮次中，此类结果可能会变为 2(b)。

设计原则

ODP 力求平衡的三大支柱：隐私性、公平性和实用性。

用于加强隐私保护的塔式数据模型

ODP 遵循从设计上保障用户隐私，在设计上默认保护最终用户的隐私。

ODP 探索如何将个性化处理移至最终用户的设备。这种方法会尽可能地将数据保留在设备上，并且仅在必要时在设备外部处理数据，从而平衡隐私性和实用性。ODP 专注于：

• 设备对最终用户数据的控制，即使数据离开设备也是如此。目的地必须是由运行 ODP 所编写代码的公有云提供商提供且经证实的可信执行环境。
• 设备可验证性，可验证最终用户数据离开设备所发生的情况。ODP 提供开源联邦计算工作负载，可帮助其采用者协调跨设备机器学习和统计分析。最终用户的设备将证明此类工作负载在可信执行环境中执行且未经修改。
• 从技术层面保证离开设备控制/可验证边界的输出的隐私（例如聚合、噪声、差分隐私）。

因此，个性化将取决于设备。

此外，企业也需要采取隐私保护措施，而平台应予以解决。这需要在其各自的服务器中维护原始企业数据。为了实现这一点，ODP 采用了以下数据模型：

1. 每个原始数据源都将存储在设备端或服务器端，以实现本地学习和推理。
2. 我们将提供算法，助力跨多个数据源做出决策，例如在两个完全不同的数据位置之间进行过滤，或跨各种数据源进行训练或推理。

在此上下文中，可能会有一个企业塔和一个最终用户塔：

商家大楼包含商家在实现个性化之前生成的数据。ODP 要求企业保留这些信息的所有权，确保只有获得授权的业务合作伙伴才能访问这些信息。
最终用户信息塔包含最终用户提供的数据（例如帐号信息和控件）、收集的与最终用户与其设备互动相关的数据，以及商家推断的衍生数据（例如兴趣和偏好）。推断的数据不会覆盖任何用户的直接声明。

我们来做个比较：在以云为中心的基础架构中，来自最终用户塔的所有原始数据都会传输到企业的服务器；相反，在以设备为中心的基础架构中，来自最终用户塔的所有原始数据都将保留在其源头，而企业的数据仍存储在服务器端。

设备端个性化融合了这两种方式的优势，即仅启用经证实的开源代码来处理可能与 TEE 中的最终用户相关的数据，并使用更加私密的输出通道来处理这些数据。

让公众参与以包容的方式寻求公平的解决方案

ODP 旨在确保为多元化生态系统中的所有参与者提供平衡的环境。我们深知这个生态系统的复杂性，它包含提供不同服务和产品的各方参与者。

为鼓励创新，ODP 提供了可由开发者及其所代表企业实现的 API。设备端个性化有助于这些实现方式无缝集成，同时管理版本、监控功能、开发者工具和反馈工具。设备端个性化不会创建任何具体的业务逻辑；而是作为发挥创意的催化剂。

随着时间的推移，ODP 会提供更多算法。如需确定适当的特征级别，并潜在地为每个参与的企业确定合理的设备资源上限，与生态系统携手合作至关重要。我们期待收到生态系统的反馈，这有助于我们识别新的应用场景并确定其优先级。

用于改善用户体验的开发者实用工具

使用 ODP 时，不会丢失事件数据，也不会丢失观察延迟信息，因为所有事件都是在设备级别本地记录。没有联接错误，并且所有事件都与特定设备相关联。因此，观察到的所有事件会自然地形成一个反映用户互动情况的时间序列。

这一经过简化的过程无需联接或重新排列数据，可实现近乎实时且无损的用户数据访问。反过来，这可以增强最终用户在与数据驱动型产品和服务互动时感知的效用，从而可能给用户带来更高的满意度和更有意义的体验。借助 ODP，企业可以有效地适应用户的需求。

隐私保护模型：通过机密性实现隐私保护

以下部分讨论了作为此隐私分析基础的使用方-生产方模型，并介绍了计算环境隐私性与输出准确性。

作为此隐私分析基础的使用方-生产方模型

我们将采用使用方-生产方模型，检查“通过机密性实现隐私保护”模型的隐私保障情况。此模型中的计算表示为由节点和子图组成的有向无环图 (DAG) 内的节点。每个计算节点包含三部分：使用的输入、生成的输出以及将输入映射到输出的计算。

展示使用方-生产者模型的图表。此图有 2 个计算节点。执行序列为节点 1 -> 节点 2。节点 1 是第一个执行节点。它会使用 2 个初始输入：输入 1 和输入 2。节点 1 生成输出 1。节点 2 使用节点 1 的输出和初始输入：输入 3。它会生成输出 2。输出 2 也是此图的最终输出。

在此模型中，隐私保护适用于所有三个组成部分：

• 输入隐私。节点可以包含两种类型的输入。如果输入由前驱节点生成，则该输入已获得该前驱节点的输出隐私保证。否则，输入必须使用政策引擎获取数据入站政策许可。
• 输出隐私。输出可能需要进行私有化，例如差分隐私 (DP) 提供的输出。
• 计算环境机密性。计算必须在安全密封的环境中进行，确保没有人可以访问节点内的中间状态。可实现此功能的技术包括联邦计算 (FC)、基于硬件的可信执行环境 (TEE)、安全多方计算 (sMPC)、同态加密 (HPE) 等。值得注意的是，“通过机密性实现隐私保护”可保护中间状态，而离开机密性边界的所有输出仍需要通过差分隐私机制保护。两项必需的声明包括：
  • 环境机密性 - 确保只有声明的输出才会离开环境；
  • 可靠性 - 能够通过输入隐私声明准确推断输出隐私声明。可靠性允许隐私属性沿 DAG 向下传播。

私有系统可保证输入隐私、计算环境机密性和输出隐私。但是，可以通过在机密计算环境内封闭更多的处理来减少差分隐私机制的应用次数。

此模型有两大优势。首先，大多数大大小小的系统都可以表示为 DAG。其次，DP 的 后期处理 [第 2.1 节] 和 组合 差分隐私复杂度的词元 2.4 属性提供了强大的工具，用于分析（最坏情况下）整个图表在隐私和准确性方面的权衡取舍：

• 后处理可保证在某个量被私有化后，如果原始数据不再使用，则无法将这个量“取消私有化”。只要节点的所有输入都是私有的，则无论进行怎样的计算，其输出都是私有的。
• 高级组合可保证：如果图的每个部分都是 DP，那么整体图也是 DP。我们假定某个图有 κ 单元，且每个单元的输出为 (ε, δ)-DP，通过分别求得 ε√κ 的近似值，有效限定图的最终输出的 ε 和 δ。

这两个属性转化为对每个节点的两种设计原则：

• 属性 1（来自后处理）：如果某个节点的输入全部为 DP，则其输出为 DP，任何业务逻辑都可在节点中执行，并支持企业的“秘密武器”。
• 属性 2（来自高级组合）如果节点的输入并非全部为 DP，则必须使其输出符合 DP 要求。如果计算节点在可信执行环境中运行，并且执行的是设备端个性化提供的开源工作负载和配置，则可能会具有更严格的 DP 边界。否则，设备端个性化可能需要使用最糟糕的 DP 边界。由于资源限制，系统最初将优先使用公有云提供商提供的可信执行环境。

计算环境隐私性与输出准确性

因此，设备端个性化将专注于增强机密计算环境的安全性，并确保中间状态仍然无法访问。这种安全过程（称为“密封”）将在子图级别应用，使多个节点一起符合 DP 要求。这意味着，前面提到的属性 1 和属性 2 在子图级别应用。

将包含 7 个节点的图表拆分为 2 个子图和 1 个节点。在此示例中，每个子图都有 3 个节点。如果每个子图的执行都被攻击者阻止，那么只有输出 3 和输出 6（子图的结果）需要进行 DP 处理。
当然，最终的图输出 Output 7 是按组合进行 DP 的。这意味着此图表将有 2 个 DP；相比之下，如果不使用密封，则总共有 3 个（本地）DP。

从本质上讲，通过保护计算环境并消除攻击者访问图或子图的输入和中间状态的机会，这样可以实现中央 DP（即密封环境的输出符合 DP 要求），与本地 DP（即，单个输入符合 DP）相比，可以提高准确性。这一原则将 FC、TEE、sMPC 和 HPE 视为隐私保护技术的基础。请参阅《The Complexity of Differential Privacy》中的第 10 章。

模型训练和推理是一个很好的实用示例。下面的讨论假设：(1) 训练群体和推理群体重叠；并且 (2) 特征和标签构成私有用户数据。我们可以将 DP 应用于所有输入：

本地 DP：媒体资源 1 私有功能 + 私有标签 -> 私有模型。（属性 1）私有模型 + 私有特征 -> 私有推断。
设备端个性化可以在将用户标签和功能发送到服务器之前对其应用本地 DP。此方法不会对服务器的执行环境或其业务逻辑施加任何要求。

中央 DP：（属性 2）或者，您也可以在模型训练期间应用 DP，同时保持特征和标签的精确性。在此场景中，模型所有者可以将模型转移给别处进行推断。不过，根据属性 1 的规定，为了在推断过程中保护隐私，输入到私有模型的特征也必须符合 DP 标准。

您可以通过封闭训练和推断来进一步提高推断准确性。这样，您就可以将精确的特征馈送到专用模型中。

更进一步，您也可以封闭最终推断。在这种情况下，模型所有者也无法访问推断。
这是当前的设备端个性化设计。

可验证的隐私保护

设备端个性化旨在实现可验证的隐私保护体验。它侧重于验证在用户设备之外发生的情况。ODP 将编写代码来处理离开最终用户设备的数据，并将使用 NIST 的 RFC 9334 远程证明程序 (RATS) 架构来证明此类代码在符合机密计算联盟要求的实例管理员去特权服务器中运行且未经修改。这些代码将是开源的，可通过透明的验证来建立信任。此类措施可以让个人确信其数据会得到保护，并且企业可以在稳固的隐私保障基础上建立声誉。

减少收集和存储的隐私数据量也是设备端个性化至关重要的一个方面。它遵循这一原则，通过采用联邦计算和差分隐私等技术，在不暴露敏感个人详细信息或身份信息的情况下揭示有价值的数据模式。

维护用于记录与数据处理和共享相关活动的审核跟踪记录是可验证隐私保护的另一个关键方面。这让我们能够创建审核报告并识别漏洞，展示我们对隐私保护的承诺。

我们期望隐私保护专家、相关机构、行业和个人通力协作，帮助我们不断改进设计和实现方式。

下图显示了按差分隐私机制进行跨设备聚合和噪声处理的代码路径。

联合计算服务的结构，用于处理联邦学习和联合分析。未加密、不带噪声的数据只在设备上处理（红线）。无论是传输中的还是静态的，处理结果都会加密（蓝绿色线条）。只有编写了设备端个性化并且开源跨设备汇总和噪声工作负载可以在通过多方协调器成功证明后访问未加密的原始设备结果。根据可信执行环境内的差分隐私机制正确应用噪声后，所有下游数据流都可未加密（橙线）。

概要设计

如何通过机密性实现隐私保护？概括来讲，在密封环境中运行的 ODP 编写的政策引擎充当监管每个节点/子图的核心组成部分，同时跟踪其输入和输出的 DP 状态：

• 从政策引擎的角度来看，设备和服务器会被同等对待。运行相同政策引擎的设备和服务器在政策引擎经过相互证明后，在逻辑上会被视为是等同的。
• 在设备端，隔离是通过 AOSP 隔离进程实现的（从长远来看，一旦可用性变得较高时，是通过 pKVM 实现的）。在服务器端，隔离依赖于“可信方”，该方可以是 TEE 以及其他首选的技术密封解决方案，也可以是合同协议，或者以上两者兼有。

换句话说，所有安装和运行平台政策引擎的密封环境都被视为我们的可信计算基 (TCB) 的一部分。使用 TCB 时，数据可以在不添加其他噪声的情况下进行传播。当数据离开 TCB 时，需要应用 DP。

设备端个性化的概要设计有效集成了以下两个基本元素：

• 用于执行业务逻辑的配对进程架构
• 用于管理数据入站、出站和允许的操作的政策和政策引擎。

这种具有内聚力的设计为企业提供了一个公平的竞争环境，使企业可以在可信执行环境中运行其专有代码，并访问已通过相应政策检查的用户数据。

以下部分将详细介绍这两个关键方面。

用于执行业务逻辑的配对进程架构

设备端个性化在 AOSP 中引入了配对进程架构，以便在业务逻辑执行期间增强用户隐私保护和数据安全。此架构包括：

• ManagingProcess。此进程会创建和管理 IsolatedProcess，以确保它们保持进程级隔离，只能访问列入许可名单的 API，并且没有网络或磁盘权限。ManagingProcess 会处理所有企业数据和所有最终用户数据的收集工作，并针对企业代码使这些数据获取政策许可，并将其推送到 IsolatedProcess 以供执行。此外，它还协调 IsolatedProcess 与其他进程（如 system_server）之间的交互。

• IsolatedProcess。该进程被指定为隔离状态（在清单中设置为 isolatedprocess=true），会从 ManageProcess 接收企业数据、已获政策许可的最终用户数据以及企业代码。它们允许企业代码对其数据和已获政策许可的最终用户数据执行操作。IsolatedProcess 专门针对数据入站和出站与 ManageProcess 进行通信，没有其他权限。

配对进程架构提供了对最终用户数据隐私保护政策进行独立验证的机会，而无需企业将其业务逻辑或企业代码开源。ManageProcess 可保持 IsolatedProcess 的独立性，IsolatedProcess 可高效地执行业务逻辑，使得此架构可确保采用更安全、更高效的解决方案，在进行个性化处理期间保护用户隐私。

下图展示了此配对进程架构。

编写“采用者应用”的实体可能与图表中创建“采用者 apk”的实体相同，也可能不同。编写“Adopter apk”的实体与图表中“Adopter Local Store”（采用者本地商店）拥有的实体相同。

用于数据操作的政策和政策引擎

设备端个性化在平台和业务逻辑之间引入了政策强制执行层。我们的目标是提供一组工具，将最终用户和企业控制项映射到集中且可行的政策决策。然后，这些政策会跨数据流和企业全面、可靠地强制执行。

在配对进程架构中，政策引擎位于 ManageProcess 中，负责监管最终用户和企业数据的入站和出站。它还会向 IsolatedProcess 提供列入许可名单的操作。示例覆盖领域包括最终用户控制遵从、儿童保护、防止未经同意的数据共享，以及企业隐私。

此政策强制执行架构包含可以利用的三种类型的工作流：

• 通过可信执行环境 (TEE) 通信在本地启动的离线工作流：
  • 数据下载流：可信下载内容
  • 数据上传流：可信事务
• 在本地启动的线上工作流：
  • 实时服务流
  • 推理流
• 在本地启动的线下工作流：
  • 优化数据流：通过联邦学习 (FL) 实现的设备端模型训练
  • 报告数据流：通过联邦分析 (FA) 实现跨设备聚合

下图从政策和政策引擎的角度展示了此架构。

政策引擎位于设计的中心。示例（并非详尽无遗）：

• 下载：1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• 服务：1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• 优化：2（提供训练计划）-> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• 报告：3（提供汇总方案）-> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

总体而言，在设备端个性化的配对进程架构中引入政策强制执行层和政策引擎可确保经过隔离且可保护隐私的环境来执行业务逻辑，同时提供对必要数据和操作的受控访问。

分层 API Surface

设备端个性化可为感兴趣的企业提供分层 API 架构。顶层由针对特定应用场景构建的应用组成。 潜在企业可以将其数据连接到这些应用（称为“顶层 API”）。顶层 API 基于中层 API 而构建。

随着时间的推移，我们预计会添加更多顶层 API。如果顶层 API 不可用于特定应用场景，或者现有的顶层 API 不够灵活，企业可以直接实现中间层 API，这些 API 可通过编程基元提供强大的功能和更高的灵活性。

总结

设备端个性化是一个处于早期阶段的研究提案，旨在激发用户兴趣并征求用户对长期解决方案的反馈，该长期解决方案使用预计会带来高实用价值的最新且最佳的技术来解决最终用户隐私问题。

我们希望与隐私保护专家、数据分析师和潜在最终用户等利益相关方互动，以确保 ODP 符合他们的需求并解决他们的顾虑。