87、分布式环境中的上下文敏感隐私管理

分布式环境中的上下文敏感隐私管理

1. 引言

在现代信息技术应用中，隐私保护是一个主要关注点。无线、移动和嵌入式应用带来了多种新的隐私威胁，比如新类型数据的广泛可得性（如位置信息）、在用户未同意的情况下自动收集数据的可能性（通过各种传感器），以及将这些数据与用户身份自动关联（通过 RFID、手机、智能卡等个人携带标识）。

在这样动态且分布式的环境中，隐私高度依赖于上下文。也就是说，从数据所有者的角度来看，同一数据项在不同的潜在披露上下文中，可能会有不同的隐私要求。

本文聚焦于这样一种环境：用户可以使用移动和固定终端查看他们的私人数据。这些终端通过调用服务与网关协作，而私人数据可能会通过这些服务“泄露”到终端。网关由一个或多个用户控制，运行着诸如健康监测、生活方式支持、家庭自动化等特定应用目标的应用程序。网关收集无线传感器感知的数据，如身体参数、环境参数等，并根据需求进行处理。

2. 问题陈述

2.1 问题

私人数据归其所有者所有。隐私被理解为数据所有者决定其私人数据披露、存储和处理的权利。这种权利可以通过多种方式实现，例如让数据所有者指明数据的潜在接收者、在数据实际存储/处理前接受数据收集的目的，以及指定数据可以披露的情况等。

假设所有者对其私人数据披露设置限制的不同情况可以被枚举，我们将这些情况称为上下文。一个人当前所处的上下文称为其当前上下文。例如，Tom 可以决定他的位置信息应保密，但在医疗紧急情况下可以披露给救护车服务。他还可以定义其他上下文，如“在家”“慢跑”“有客人”等，在这些上下文中，他的位置信息保持保密。

我们假设每个数据所有者都定义了自己的隐私政策。对于每个可能的当前上下文，该政策会指定有权获取所有者私人数据的接收者。例如，Tom 的隐私政策可能规定在医疗紧急情况下，他的位置信息可以披露给救护车服务。

我们假设系统具有以下模型：
- 系统包含多个网关；
- 每个网关由一个或多个系统用户控制；
- 每个网关托管多个应用程序；
- 每个网关都永久部署了一个名为平台的特殊应用程序；
- 应用程序可以通过接口将数据披露给数据接收者；
- 数据接收者可以是应用程序或用户终端；
- 系统行为被建模为一系列系统状态；
- 对于每个接口，在给定状态下该接口向不同接收者披露数据的潜在范围可以静态确定（即在系统启动前已知）。

问题的陈述是：确保在每个系统状态下，系统接口上的数据披露都遵循数据所有者隐私政策所施加的限制。

例如，Tom 使用一个集成了移动设备（包括配备 GPS 的 PDA 和救护车上的移动终端）的系统。在紧急情况下，Tom 的 PDA 连接到救护车寻求帮助。此时的问题是，如何执行 Tom 的隐私政策，确保除了医疗紧急情况外，他的位置信息在其他情况下都保持保密。

2.2 假设和约束

在提出解决方案之前，我们引入一些额外的假设来限制问题的解决方案空间：
- 对于每个数据所有者，其隐私政策区分不同的私人数据类型。
- 对于每个接口，在系统配置时确定该接口可能释放的私人数据范围。在运行时，接口要么释放所有数据，要么不释放任何数据（即不允许部分披露）。
- 对于每个网关，部署在该网关的应用程序只能尝试通过相应接口披露该网关用户的私人数据。
- 对于每个系统状态，可以确定每个用户的当前上下文。
- 对于每个用户，上下文是相互排斥的（即任何时候，用户恰好处于一个当前上下文中）；但不同用户的当前上下文可能不同。
- 平台不披露私人数据，它用于系统管理目的，并为其他应用程序提供支持。

此外，我们对问题的解决方案施加以下约束：
- 隐私政策是参照上下文和数据接收者来定义的（即系统结构在这个抽象层面保持透明）。
- 应尽量减少应用程序开发人员实现隐私政策所需的工作量。

3. 解决方案

3.1 总体思路

为了控制用户私人数据的披露，我们提出一种机制，该机制根据用户的隐私政策要求，在当前上下文中“过滤”通过系统接口显示的数据。这种过滤过程会随着用户当前上下文的变化而变化，确保在用户隐私政策要求的情况下，私人数据不会被披露。

过滤操作在每个向数据接收者传递私人数据的接口上进行。数据过滤决策由 canAccess （部分）函数控制，其签名如下：

canAccess: O x R x C x I ß Boolean 

其中，O 表示数据所有者集合，R 表示数据接收者集合，C 表示上下文集合，I 表示接口集合。该函数返回一个布尔值，指示在当前上下文 c 中，给定接口 i 是否可以向接收者 r 披露所有者 o 的数据。换句话说， canAccess 决定了在特定上下文以及指定的所有者和接收者的情况下，某个接口是“打开”还是“关闭”。

canAccess 函数是从用户指定的隐私政策中推导出来的。在系统运行时，该函数会不断被评估，以根据用户上下文的变化调整私人数据的过滤。为了提高 canAccess 值的评估效率，已经提出了一些更具体的数据结构和算法。

3.2 隐私政策

我们假设系统用户的隐私政策由一个隐私矩阵表示。该矩阵指定了在不同上下文中，不同接收者类别可以看到的私人数据类型。每个数据所有者通过设置隐私矩阵中的相应控制项（“√”表示“披露”，“–”表示“不披露”）来声明其隐私政策。

上下文	接收者类别 1	接收者类别 2	接收者类别 3
上下文 1	数据类型 1 √ 数据类型 3 √	数据类型 1 √	数据类型 2 √ 数据类型 4 √
上下文 2	数据类型 1 - 数据类型 3 -	数据类型 1 √ 数据类型 2 √	数据类型 3 √ 数据类型 4 √

从形式上看，我们可以将隐私政策表示为一个函数 PrivPol ，其签名如下：

PrivPol: O  f P (C x RC x  DT x Boolean) 

其中，RC 是可能的接收者类别集合，DT 是可能的私人数据类型集合。

私人数据接收者到接收者类别的映射由辅助映射函数指定：

mapping: O ß RC x R 

需要注意的是，如果一个网关由多个用户控制，可能会出现隐私政策冲突的情况。例如，当两个用户对同一数据类型在不同上下文中有不同的披露要求时，就会产生冲突。一般来说，可以通过以下策略解决这种冲突：
- 寻求共识：只有当所有相关用户在其隐私政策中都允许披露数据时，才释放该数据。
- 阈值决策：只要有一个用户在其隐私政策中允许披露数据，就释放该数据（对于多个用户的情况，可以将其推广为基于阈值的决策）。
- 消除冲突：让数据接收者指定数据的预期所有者，然后根据该所有者的政策进行决策。

在本文描述的机制中，我们采用消除冲突的策略，但也可以实现其他策略。

3.3 系统配置

我们假设系统配置相关的以下信息是可用的：
- 对于系统中部署的每个应用程序，在系统配置时确定其接口列表，以及每个接口暴露的私人数据类型列表。
- 对于每个接口，给出所有可能的接收者类别列表。

这些信息由 appInfo 函数表示，该函数为每个应用程序指定一组三元组，每个三元组包含：应用程序暴露的接口、该接口暴露的私人数据类型，以及预期作为该接口数据消费者的接收者类别。

appInfo: A f P (I x P DT x P RC) 

此外，在系统运行时还会维护以下信息：
- 网关用户的标识：

own: Gw j O 

其中，Gw 是所有网关的集合。
- 每个网关部署的应用程序的标识：

conf: Gw j A 

其中，A 是系统中部署的所有应用程序的集合。

上述信息可用于自动计算每个用户的隐私矩阵，初始时，矩阵中用户定义的条目设置为“不披露”的默认值。

3.4 做出隐私相关决策

隐私相关决策是通过不断评估 canAccess 函数的值来做出的，以决定是否通过系统接口释放私人数据。该函数根据系统中提交和维护的信息（在 3.2 和 3.3 节中描述）进行评估。

首先，从 PrivPol 、 appInfo 和 conf 函数计算一个辅助函数 canAccess’ ，其签名如下：

canAccess’: O x RC x C x I ß Boolean 

canAccess’ 的值根据以下规则生成：在给定上下文中，只有当接收者类别在数据所有者的隐私政策中被允许获取该接口在该上下文中可能披露的所有数据类型时，接口才能向该接收者类别披露数据。

例如，Tom 在进行体育锻炼时，他使用的跑步机作为一个网关，暴露了用于运动监测的接口 i。跑步机发布的速度、距离、脉搏和心率等数据属于运动信息和健康信息两种数据类型。如果 Tom 希望他的教练能够获取他的运动信息，那么他也必须允许教练获取他的健康信息。为了分离运动信息和健康信息，这些数据类型应该通过不同的接口发布。在当前的隐私管理机制实现中，这样的决策需要在应用程序开发阶段做出。

如果用户重新定义了其隐私政策或系统配置发生变化， canAccess’ 函数需要重新计算。

从 canAccess’ 和 mapping 函数计算 canAccess 的值，遵循的原则是：如果接收者 r 至少属于一个被数据所有者 o 授权通过接口 i 查看其私人数据的接收者类别 rc，那么 r 可以从接口 i 获取数据。

3.5 平台

为了让应用程序无需管理隐私，并将隐私相关决策本地化，我们引入了平台的概念。平台是一个永久部署在每个网关的应用程序，负责做出隐私相关决策。

当应用程序收到通过其接口释放私人数据的请求时，它会将以下描述符转发给平台：<数据接收者 ID，被调用接口 ID，数据所有者 ID>。例如， 表示 John 请求从接口 i 获取属于 Tom 的数据。

平台使用接收到的描述符以及 Tom 的当前上下文信息来评估 canAccess 函数，并以布尔值的形式决定是否处理该请求。

为了提高效率， canAccess 可以预先计算，其相关部分可以与网关用户的当前上下文信息一起存储在每个网关上。如果这些信息发生变化（如隐私政策更改、系统配置更改等），新的值会重新分发到各个网关。实际上，只需要关注控制给定网关的用户的当前上下文，并维护与这些用户隐私政策相关的 canAccess 部分即可。

这种解决方案的结果是，隐私管理对应用程序几乎是透明的。唯一需要关注隐私管理的地方是应用程序接口，在通过接口释放数据之前，需要遵循一个简单的编码协议：调用平台请求许可。

4. 概念验证

上述机制是在 Angel 项目的背景下开发的。该项目的目标是开发和演示无线传感器网络。通过这个项目，验证了该隐私管理机制在实际应用中的可行性和有效性。

下面是一个简单的 mermaid 流程图，展示了隐私管理的主要流程：

graph LR
    A[应用程序收到数据请求] --> B[转发请求到平台]
    B --> C{平台评估 canAccess 函数}
    C -->|允许| D[释放数据]
    C -->|不允许| E[忽略请求]

综上所述，这种上下文敏感的隐私管理机制为分布式环境中的隐私保护提供了一种有效的解决方案，它能够根据用户的上下文和隐私政策灵活控制私人数据的披露，同时尽量减少对应用程序的影响。

5. 与其他工作的比较

在隐私管理领域，已经有许多相关的研究和工作。与其他一些隐私管理方法相比，本文提出的机制具有独特的优势。

一些传统的隐私管理方法可能没有充分考虑上下文的敏感性。它们往往采用静态的规则来控制数据披露，无法根据用户当前所处的不同上下文动态调整隐私策略。例如，在某些方法中，无论用户是处于工作场景还是休闲场景，对数据披露的限制都是固定的，这可能导致在某些情况下过度保护或保护不足。

而本文的机制通过引入上下文的概念，能够根据用户的当前上下文动态地过滤数据。例如，在医疗紧急情况下，允许披露用户的位置信息给救护车服务，但在其他正常情况下，位置信息保持保密。这种上下文敏感的方法更加灵活和智能，能够更好地满足用户在不同场景下的隐私需求。

另外，一些隐私管理方法可能将隐私决策集中在一个中心节点进行处理。这种集中式的方法可能会导致性能瓶颈，尤其是在大规模分布式系统中。当系统中的数据请求量较大时，中心节点可能会成为系统的性能瓶颈，影响系统的响应速度和稳定性。

本文的机制将隐私决策本地化到各个网关的平台上。每个网关的平台独立地根据本地的上下文信息和隐私政策做出决策，减少了对中心节点的依赖。这样不仅提高了系统的性能和可扩展性，还增强了系统的安全性。因为即使某个网关出现故障或被攻击，也不会影响其他网关的隐私管理功能。

6. 结论

本文提出了一种用于分布式环境的上下文敏感隐私管理机制。该机制旨在解决在动态和分布式环境中，隐私高度依赖于上下文的问题。通过对用户的私人数据进行上下文敏感的过滤，确保在每个系统状态下，数据披露都遵循数据所有者的隐私政策。

6.1 机制的优势

• 灵活性 ：该机制能够根据用户的当前上下文动态调整隐私策略，适应不同的场景需求。例如，用户可以根据自己所处的不同上下文（如医疗紧急、在家、工作等），灵活地控制其私人数据的披露。
• 本地化决策 ：隐私决策被本地化到各个网关的平台上，减少了对中心节点的依赖，提高了系统的性能和可扩展性。同时，这种本地化的方法也增强了系统的安全性，因为每个网关可以独立地处理隐私决策，降低了单点故障的风险。
• 对应用程序透明 ：隐私管理对应用程序几乎是透明的，应用程序只需要在通过接口释放数据之前调用平台请求许可。这大大减少了应用程序开发人员实现隐私政策所需的工作量，提高了开发效率。

6.2 未来展望

虽然本文的机制在隐私管理方面取得了一定的成果，但仍有一些方面可以进一步改进和扩展。
- 更复杂的上下文模型 ：目前的上下文模型相对简单，只考虑了一些基本的上下文情况。未来可以引入更复杂的上下文模型，例如考虑用户的社交关系、时间因素、环境因素等，以提供更精细的隐私控制。
- 多策略融合 ：在处理隐私政策冲突时，目前只采用了一种冲突消除策略。未来可以考虑将多种冲突解决策略进行融合，根据不同的场景和需求选择最合适的策略，以提高系统的灵活性和适应性。
- 与其他安全机制的集成 ：可以将该隐私管理机制与其他安全机制（如加密技术、访问控制技术等）进行集成，以提供更全面的安全保护。例如，在数据传输过程中使用加密技术，进一步增强数据的安全性。

6.3 总结

上下文敏感的隐私管理机制为分布式环境中的隐私保护提供了一种有效的解决方案。它通过灵活的上下文过滤和本地化决策，能够更好地满足用户在不同场景下的隐私需求，同时减少对应用程序的影响。随着信息技术的不断发展，隐私保护将变得越来越重要，这种机制有望在未来的分布式系统中得到更广泛的应用。

以下是一个总结表格，展示了该机制的主要特点和优势：
| 特点 | 描述 |
| — | — |
| 上下文敏感 | 根据用户的当前上下文动态过滤数据，适应不同场景需求 |
| 本地化决策 | 隐私决策本地化到各个网关的平台上，提高性能和可扩展性 |
| 对应用程序透明 | 应用程序只需在释放数据前调用平台请求许可，减少开发工作量 |

下面是一个 mermaid 流程图，展示了该机制的整体架构：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[用户终端]:::process -->|数据请求| B[应用程序]:::process
    B -->|请求转发| C[平台]:::process
    D[无线传感器]:::process -->|数据收集| E[网关]:::process
    E -->|数据处理| B
    C -->|隐私决策| B
    B -->|数据披露/拒绝| A

综上所述，这种上下文敏感的隐私管理机制在分布式环境中具有重要的应用价值，为解决隐私保护问题提供了一种可行的方案。未来，通过不断的改进和扩展，该机制有望在更多领域发挥更大的作用。