隐私原则

一个人的自主性是指其根据自身个人意愿作出 决定的能力， 而不受其他行为者的不当影响。人们用于权衡决策的智力资源 和 时间有限，因此在作出决策时不得不依赖捷径。这使得 操纵他们的偏好成为可能， 包括他们的隐私偏好（[Privacy-Behavior]， [Digital-Market-Manipulation]）。 当一个系统提供的捷径更接近于某个人在拥有无限时间和智力 能力的情况下会作出的决定时，该系统就提升了这个人的自主性。 如果类似的捷径与在这些理想条件下作出的决定相违背，则会降低这个人的自主性。

降低自主性的可供性和交互被称为欺骗性 模式（或暗黑模式）。 欺骗性模式不一定是故意造成的（[Dark-Patterns]，[Dark-Pattern-Dark]）。 在构建可能影响人们自主性的事物时， 重要的是由来自多个独立视角的审阅者 检查它是否引入了欺骗性模式。

鉴于当今数据经济中潜在的与数据相关的决定数量极大， 人们不可能详细控制其数据如何被处理。 这一事实并不意味着隐私已经消亡。研究表明， 人们仍然关心其数据如何被处理，他们感到无能为力， 并认为自己已经失去了能动性（[Privacy-Concerned]）。 如果我们谨慎设计我们的技术基础设施， 就可以让人们在自己的数据方面拥有更大的自主性。这可以 通过设置适当的、保护隐私的默认值，并设计 用户友好的选择架构来实现。

有时，某些特定人群，例如儿童或老年人， 会被归类为脆弱人群。但是，任何人都可能在 一个或多个上下文中处于脆弱状态，有时甚至自己并未意识到。 一个人披露个人数据时，可能没有意识到自己处于脆弱状态 或可能变得脆弱，而一个参与者可能 无从得知某个人处于脆弱状态。 系统设计者应在系统设计中考虑这一点。

由于以下原因，一些人可能更容易因 个人数据的收集、滥用、丢失或被盗而遭受隐私风险或伤害：

• 由于其属性、兴趣、观点或行为；
• 由于所处的情形或环境（例如存在信息不对称或其他 权力失衡）；
• 他们缺乏充分评估风险的能力；
• 选择没有以易于理解且有意义的方式呈现（例如欺骗性模式）；
• 没有就其隐私需求和期望征询他们的意见；
• 在有关产品或服务设计的决策中 没有考虑他们。

对于脆弱人群的个人数据，或一旦其个人数据被收集、使用或 共享便可能导致某人变得脆弱的敏感信息， 可能需要额外的隐私保护（例如阻止跟踪元素、传感器数据或有关 已安装软件或已连接设备的信息）。

虽然有时其他人可以帮助脆弱人群评估隐私风险并 作出有关隐私的决定（例如父母、监护人和同伴），但每个人 都拥有自己的隐私权。

隐私原则通过社会过程来定义，因此，在特定上下文中适用的 隐私定义可能存在 争议（[Privacy-Contested]）。 这使隐私成为一个集体行动问题（[GKC-Privacy]）。 群体层面的数据处理可能影响群体或个人，包括以 即使在对同意作出乐观假设的情况下，人们也无法控制的方式产生影响。例如， 某个人可能只愿意向某个特定参与者透露自己属于某个群体。然而，同一群体中的其他成员可能正在与同一 参与者交互，并披露更多信息，这可能使参与者能够有效地对 那些不提供自身信息的人作出统计推断。

因此，我们考虑的不仅仅是分享数据的人们与邀请其分享数据的参与者之间的关系（[Relational-Turn]），还要考虑 即使没有分享数据，也可能发现自己被间接归类为某个群体成员的人们 之间的关系。这里一个关键认识是，即使数据已经去标识化，这种关系仍可能持续存在。更 重要的是，无论这种对人的分类是否自愿，都会改变世界运行的方式。 这可能产生自我强化的循环，从而同时损害个人和 群体（[Seeing-Like-A-State]）。

一般而言，数据中的集体问题需要集体解决方案。 Web 标准通过 在用户代理中定义结构性控制、 确保研究人员和监管机构能够发现群体层面的滥用， 并建立能够处理隐私问题的机构或将职责委托给这类机构，来协助数据治理。 如果治理主要依靠 增加个人控制而不是集体行动，通常很难实现其目标。

大规模收集数据可以产生显著的亲社会结果。问题往往在 参与者同时为了集体利益和不忠诚的目的处理数据时出现。 这些不忠诚的目的通常被辩称是在为亲社会结果提供资金支持， 但要使这种做法适当，就需要集体监督。

用户代理充当 一个人（其用户）与 Web 之间的中介。 用户代理在 可能的范围内实现集体治理为个人利益而确立的原则。 它们力图防止形成信息不对称，并通过提供自动化来服务其用户，以纠正 自动化不对称。在可能的情况下，它们保护 其用户免于收到 侵入性消息。

用户代理应当 与使用它的人完全保持利益一致，并完全 为这个人的利益而运行。它不是第一方。用户代理作为一个可信代理来服务这个 人： 它始终将这个人的利益置于首位。在某些情况下，这可能意味着通过阻止 这个人作出危险决定， 或通过放慢其作出决定的速度，来保护这个人免受自身行为的伤害。例如， 如果无法验证某个站点的真实性， 用户代理会让某人难以 连接到该站点。它会检查这个人是否确实打算 向页面暴露敏感设备。它会阻止这个人同意 永久监控其行为。其用户代理义务包括 （[Taking-Trust-Seriously]）：

保护义务

保护要求用户 代理主动保护其用户的数据，而不仅仅 采取简单的安全措施。仅对静态数据和传输中的数据进行加密是不够的。 用户代理还必须 限制数据保留，帮助确保只收集严格 必需的数据，并要求任何用户代理能够合理意识到数据被共享给的参与者提供保障。

审慎义务

审慎要求用户代理通过谨慎处理其披露所管理的个人数据的方式， 尽最大努力执行相关原则。审慎并不等于 保密或秘密：即使用户代理共享了一些个人数据，只要 是以适当审慎的方式进行，仍可保持信任。

诚实义务

诚实要求用户代理向其用户 提供用户代理能够合理掌握的、与其相关并能提高其 自主性的信息，只要用户能够理解这些信息，并且存在适当的 时机。这个时机几乎绝不会是在这个人正试图 做其他事情时，例如阅读页面或激活某个功能。诚实义务远远超出 较旧隐私制度中经常包含的透明度义务。与透明度不同，诚实 不能将相关信息隐藏在复杂的法律声明中，也不能依赖 同意对话框中提供的极短摘要。 如果这个人已经同意对其个人数据进行处理， 则用户代理应 向这个人告知正在进行的处理， 并且其明显程度应与该处理可合理预见的影响成比例。

忠诚义务

由于用户代理 是一个可信代理，因此它在所有情况下都应忠于 使用它的人，甚至应优先于 用户代理的 实现者。 当用户代理 执行损害其用户利益而使另一个参与者受益的处理时，这就是不忠诚。通常这会使 用户代理自身受益， 在这种情况下称为“自利交易”。即使某项行为与符合人利益的处理同时进行，它仍然可能是不忠诚的，重要的是 它可能与这个人的利益发生冲突。此外，还 必须牢记，额外的处理几乎总是意味着额外的风险。因此， 并非明确符合用户利益的处理 很可能是不忠诚的。 不忠诚始终是不适当的。

这些义务确保用户 代理会关照其用户。在学术 研究中，与可信代理之间的这种关系通常被称为 “信义关系” （[Fiduciary-Law]，[Fiduciary-Model]，[Taking-Trust-Seriously]； 更长的非正式讨论请参见 [Fiduciary-UA]）。某些司法管辖区可能对 “信义”具有不同的法律含义。（[Fiduciary-Law]）

本文档其余部分描述的许多原则扩展了用户代理的义务，并 使其更加精确。

虽然隐私原则旨在协同工作并相互支持， 但偶尔，某项旨在改进系统遵循某个隐私原则方式的提案可能会降低 系统遵循另一个原则的程度。

一旦需要在帕累托前沿上的不同设计之间进行选择， 应优先考虑哪些隐私原则就是一个复杂问题，并且很大程度上取决于每个 具体情形的细节。请注意，人们的隐私也可能与 非隐私方面的考虑发生冲突。正如Web 伦理原则中所讨论的，“ 重要的是 考虑特定技术所应用的上下文、该技术的预期 受众、谁会从该技术中受益以及谁可能因此处于不利地位， 以及其中涉及的任何权力动态”（[Ethical-Web-Principles]）。尽管存在这种复杂性， 仍有一条基本 规则需要遵循：

如果某人违反了他们正在使用的服务的规则， 就认为他们会按比例牺牲一部分隐私保护，这种说法很有吸引力，但是

1. 服务通常只能通过同时收集 无辜用户的数据来防止规则被违反。这种额外收集并不总是适当的， 尤其是在它 允许进行普遍监控时（[RFC7258]，[RFC7687]）。
2. 如果服务运营者想收集一些额外数据，他们可能会受到诱惑， 去定义允许自己这样做的规则和比例原则。

以下示例说明了一些冲突：

一个人的身份是定义 这个人的一组特征。其在某个上下文中的身份是他们 在特定情况下呈现的一组特征。

人们可以向不同上下文呈现不同的身份，也可以 在多个不同上下文中共享同一身份。

人们可能希望呈现临时或匿名身份。这是 一组过少或过于不稳定、因而无法用于 随时间跟踪他们的特征。

一个人的身份往往可能与其持有的任何法定身份 不同。

在某些情况下，用户代理遵守这一 原则的最佳方式是阻止识别（例如，使一个站点无法 获知其用户在另一个站点上的行为）。

在其他情况下，用户代理遵守这一 原则的最佳方式是支持识别（例如，帮助其用户向 一个站点 证明自己在另一个站点上具有特定身份）。

类似地，用户代理可以 通过在对同一站点的重复访问之间阻止或支持 识别，来帮助其用户。

用户代理应尽最大努力 区分站点内的上下文， 并根据其用户的意愿调整其分区，以在这些站点内部的上下文之间阻止或支持识别。

数据最小化限制了数据被披露或滥用的风险。它还 帮助用户代理和其他 参与者更有意义地解释其用户需要 作出的决定。有关更多信息，请参见Web API 中的数据最小化。

数据最小化原则适用于所有个人数据，即使 尚不知道它是否具有识别性、敏感性或其他危害性。参见： 2.4 敏感信息。

网站可用的大量 API 暴露了大量数据，这些数据可以组合 成有关人们、Web 服务器和其他事物的信息。

由用户控制的设置或权限可以保护 对 Web 上数据的访问。在设计 Web API 时，应使用访问保护 来确保 API 以适当的方式暴露信息。

增加获取信息新方式的新 API 必须 至少受到与现有方式同样严格的保护。

在一组访问保护下可以接受暴露的信息，在 另一组保护下可能 不可接受。当 API 设计者打算以现有可接受 API 已经暴露相同信息为理由， 说明其新 API 可以接受时， 必须谨慎确保其新 API 仅在一组至少同样严格的保护 下可用。如果没有这些保护，就需要 从头论证，而不能依赖现有 API。

如果现有 API 提供了对某些信息的访问，但已有计划 修改这些 API 以阻止这种访问，则不得添加 提供相同信息的新 API，除非它们包含额外的 访问保护，以确保访问是适当的。

例如，浏览器正在逐步移除在不同分区之间关联身份的能力。重要的是，新 API 不要添加 会重新启用跨上下文识别的功能。

有关某人的许多信息一旦被披露，都可能造成隐私损害。 例如：

• 其位置。
• 语言偏好。
• 与其相关联的任何标识符。
• 来自其摄像头或麦克风的视频或音频。
• 其文件系统中某些文件的内容。
• 财务数据。
• 联系人。
• 日历条目。
• 他们是否 正在使用辅助技术。

某项特定信息对于不同 人可能具有不同的敏感程度。如果有关人们的敏感信息已经或可能 被暴露，他们可能会变得脆弱；参见1.2 脆弱性。

虽然仅靠数据权利不足以满足 Web 的所有隐私原则，但它们 确实支持自决，并有助于提高问责性。这些权利包括：

• 访问有关自身数据的权利。

这项权利既包括能够查看已经收集或推断出的有关 自身的信息，也包括能够发现哪些参与者收集了有关自身的信息。因此， 包含有关人们信息的数据库不能保持 秘密，而且收集的有关人们的数据需要能够被这些人以有意义的方式 发现。

• 删除有关自身数据的权利。

一个人有权删除关于自己的信息，无论 其是否完全终止使用某项服务，尽管在这两种情况下可以删除哪些 数据可能有所不同。在 Web 上，一个人可能希望删除 其设备上的数据、服务器上的数据或两者，而这个人可能并不总能明确知道 数据的位置。

• 移植 数据的权利，包括自己存储在另一个参与者处的数据，以便可以轻松复用或 转移到其他地方。

可移植性对于支持一个人在具有 不同数据实践的服务之间作出选择的能力是必要的。互操作性标准对于有效复用至关重要。 移植用户数据涉及 [Portability-Threat-Model] 中描述的安全和隐私风险。

• 更正有关自身数据的权利，以 确保自己的 身份在系统中得到正确体现。

• 免受基于有关自身数据的自动化 决策的权利。

对于某些会产生重大后果的决策，能够 将自己排除在自动化画像之外是一种隐私利益。例如，某些服务可能会根据 收集到的有关某人的数据改变商品价格（价格歧视）或信贷、保险报价。 这些改变可能产生重大后果（例如在财务方面），并且 那些认为基于有关自身数据作出的决定不准确或 不公正的人可能会对此表示反对。再例如，一些服务可能会根据 对摄像头数据运行的面部识别算法，推断用户的身份、是否为真人或 是否在场。由于面部识别 算法和训练集并非绝对可靠，并且可能表现出某些偏差，人们可能不愿 接受基于此类自动化识别作出的决定。

• 反对、 撤回同意和限制使用有关自身数据的权利。

人们可能改变其有关同意的决定，也可能反对随后对有关 自身数据的使用。数据权利意味着一个人需要持续拥有控制权，而不仅仅是在 收集时拥有一次选择。

OECD 隐私原则 [OECD-Guidelines]、 [Records-Computers-Rights] 和 [GDPR] 等 文献描述了人们作为数据 主体所享有的许多权利。人们对有关自身数据的这些参与性 权利是自主性所固有的。

当有很高的置信度认为，数据所描述的任何人都无法通过该数据本身或与其他可用信息结合后被直接或 间接识别 （例如通过与标识符、用户代理或设备关联）时，数据即为去标识化数据。许多当地法规为数据被视为去标识化规定了额外要求，但这些要求不应 被视为隐私保护程度的上限。请注意， 与群体有关的进一步考虑在 隐私中的集体问题一节中讨论。

当满足以下条件时，我们称之为受控去标识化数据：

1. 数据的状态是，可用于重新识别某个 个人的信息已经被移除或更改，并且
2. 存在一个过程来防止尝试重新识别人们以及意外 泄露去标识化数据。（[De-identification-Privacy-Act]）

涉及受控去标识化数据的不同情况将需要 不同的控制措施。 例如，如果受控去标识化 数据仅由一个 参与者处理，典型的控制措施包括确保数据中使用的标识符仅对 该数据集唯一；任何能够访问该数据的人（例如该参与者的员工）都被 禁止（例如基于法律条款）进一步共享该数据；并且存在技术措施 防止重新识别或合并涉及该数据的不同数据集。

一般而言，目标是确保受控去标识化数据的使用方式 能提供切实可行的监督和问责程度，从而确保用于 保持假名性的技术和程序手段得以维持。

当受控去标识化数据在多个 参与者之间共享时，这会更加困难。在这种情况下，代表最佳 实践的典型控制措施的良好示例包括确保：

• 数据中使用的标识符由第一方（即一个人直接交互的参与者）直接且独占控制，并且严格的控制措施 阻止其将标识符与数据进行匹配；

• 当这些标识符与第三方共享时，它们对于该第三方是唯一的，因此如果与多个 第三方共享，这些第三方便无法相互匹配这些标识符；

• 有很高的置信度认为，任何第三 方都无法将该数据 与通过和第一方交互获得的数据之外的任何其他数据进行匹配；

• 接收此类数据的任何第三方都被禁止（例如基于法律条款） 进一步共享该数据；

• 存在防止重新识别或合并 涉及该数据的不同数据集的技术措施；并且

• 第一 方和第三方之间存在合同条款， 描述共享数据所针对的有限目的。

请注意，受控去标识化 数据本身不足以使 数据处理成为适当的。

隐私原则通常以向个人扩展权利的方式来定义。但是，在某些 情况下，代表群体集体决定适用哪些原则是最佳方式。 应在以下情况下考虑集体决策：

• 当信息涉及群体成员身份或群体行为时。 正如 Brent Mittelstadt 所解释的，“由算法归为一组的 个人，对有关群体的信息的创建以及 代表该群体采取的行动具有共同利益。”（[Individual-Group-Privacy]） 正如1.3.1 群体隐私 所讨论的， 单个个人的许可不足以支持群体其他 成员的自主性。
• 当无法合理预期个人能够作出知情决定时。 当数据处理很复杂， 或处理数据的请求非常频繁时，可能出现这种情况。
• 当个人相对于要求其同意数据处理的组织而言，系统性地处于更弱势的地位时 （[Relational-Turn]）。
• 当数据处理在社会层面是不公正的，即使 个人仍保持匿名（[Relational-Governance]）。

根据正在处理的数据不同，不同形式的集体决策具有正当性。 这些形式可能包括不同行政级别的政府机构、标准 组织、劳动者谈判团体或公民社会论坛。 即使集体决策可能优于将 隐私劳动转嫁给个人，它也不是 万灵药。 决策机构需要谨慎设计， 例如使用制度 分析与发展框架。

计算设备具有管理员，他们 拥有对设备的特权访问权限，以便安装和配置 在设备上运行的程序。设备的所有者可以 授权一个管理员管理整个 设备。 某些用户代理实现还可以 根据登录其中的账号分配一个管理员来 管理特定的用户 代理。

有时，使用设备的人并不拥有该设备，也没有 对其的管理员访问权限（例如，雇主向 员工提供设备；朋友将设备借给客人；或父母向 年幼的孩子提供设备）。另一些时候，设备的所有者和主要用户 可能并不是唯一拥有管理员访问权限的人。

这些关系可能涉及权力失衡。儿童可能难以访问父母提供的设备 之外的任何计算设备。遭受虐待的受害者可能无法 阻止其伴侣拥有对其设备的管理员访问权限。员工可能 为了保住工作而不得不同意使用雇主的设备。

虽然设备所有者有利益、有时也有责任确保其设备 按照其预期方式使用，但使用该设备的人在 使用设备时仍然享有隐私权。该原则通过两种方式保障这一隐私权：

1. 用户代理开发者 需要考虑设备所有者和 管理员的请求是否合理，并拒绝实现 不合理的请求，即使这 意味着销量减少。在利益相关方 优先级中，所有者/管理员的需求并不优先于用户需求。
2. 即使信息披露是合理的，其数据正在被披露的人 也需要知道这一点，以便避免做出会导致不希望出现的 后果的事情。

某些管理员请求对于某些类型的 用户（例如员工或儿童）可能是合理的，但对于其他类型（例如朋友或亲密伴侣）则可能不合理。 用户代理应 以有助于不同用户作出适当反应的方式解释管理员将了解到哪些信息。

数字滥用是 通过数字手段虐待一个人。在线骚扰 是“通过有害行为在网上对个人或群体进行普遍或严重的针对” [PEN-Harassment]， 并构成一种滥用形式。骚扰是 Web 上普遍存在的问题， 尤其是在社交媒体上。虽然骚扰可能影响任何使用 Web 的人，但对于 LGBTQ 人群、女性、种族或族裔 少数群体、残障人士、脆弱人群和其他边缘化 群体而言，骚扰可能更严重，其后果也可能影响更大。

骚扰本身既是对隐私的侵犯，也可能由 其他隐私侵犯行为促成或加剧。

骚扰可能包括：发送不需要的信息；指使 他人联系或骚扰某个人（“围攻”）；披露有关某人的敏感信息； 发布关于某人的虚假信息；冒充某人；侮辱；威胁；以及 仇恨或贬损性言论。

披露身份识别或联系信息（包括“人肉搜索”）通常可被用于使 更多攻击者持续发送构成骚扰的不需要的信息。 披露位置信息可被用于侵扰一个人的 人身安全或个人空间。

举报机制属于缓解措施，但可能无法阻止骚扰，尤其是在 托管方、版主或其他中介支持或参与滥用的情况下。

有效举报很可能需要：

• 用于标识滥用举报联系人的标准化机制；
• 站点和用户代理提供可见且可用的方式来举报滥用；
• 用于指代发送者和内容的标识符；
• 提供上下文和说明伤害的能力；
• 负责及时响应举报的人员；
• 用于汇集缓解信息的工具（参见示例 13）。

不需要的 信息涵盖了广泛的未经请求的通信，从 单独来看通常无害但汇集起来会造成滋扰的消息（垃圾信息），到 发送露骨、令人不适或暴力的图像。

系统设计者应采取措施，使发送不需要的信息变得更加困难 或成本更高，并使发送者承担更多责任。

为特定目的而设计的功能通过提供仅用于或主要 用于特定目的的功能来促进这些原则。为特定目的而设计的功能使向 人们解释目的变得更容易，并且还可能 限制数据可行的次要用途。在构建为特定目的而设计的功能时， 应考虑高级 API 与低级 API 之间的权衡。

受控去标识化数据可以以与所说明 目的兼容的方式用于其他目的。

透明度是同意的必要条件，但并不充分。相关说明性 信息包括谁正在访问数据、访问哪些数据（包括可能从这些数据中作出的 推断或这些数据的组合），以及如何使用数据。为了使透明度对 人们有意义，说明性信息必须在相关上下文中提供。

以机器可读方式呈现与隐私相关的实践，对于用户代理 能够帮助人们作出一般性决定是必要的，而不是错误地依赖 人们能够或愿意在每次访问网站之前阅读文档这一 想法。机器可读的 呈现方式还通过使研究人员和监管机构更容易发现、记录和分析数据收集与 处理，以识别可能造成伤害的情况，从而促进集体治理。

以易于访问的通俗语言呈现与隐私相关的实践，对于 人们在选择这样做时，能够在具体情况下作出知情决定是必要的。 站点、用户代理以及其他参与者都可能需要以无障碍形式向人们呈现与隐私相关的实践。

不透明的识别方法之所以有害，部分原因是它们对 用户不可见，从而削弱了用户控制 [Unsanctioned-Tracking]。设计能够 最大限度减少数据并明确发出数据请求的功能，可以实现可检测性——一种透明度形式，它是 缓解浏览器 指纹识别的重要措施。

试图获得对不符合这个人 真实偏好的处理的同意，会给这个人强加不希望承担的隐私劳动，并可能 导致人们错误地给予后来会后悔的同意。

如果一个人不太可能拥有足够信息来作出是否同意的知情决定， 参与者就不应提示其给予同意。 在考虑一个人是否掌握足够信息、可以被要求给予同意时， 参与者应实事求是地评估理解其请求同意的处理 需要多少时间和精力。 仅仅提供一个指向复杂政策的链接，不太可能意味着这个人已经知情。

避免通过同意请求打断用户的替代方法示例包括：

• 考虑站点受众和类别中的信息共享规范， 并仅请求与站点目的相适应的同意。 （例如，照片共享站点的 用户可能预期系统会提示其同意分享自己 上传的作品。）站点应考虑开展有关 人们对数据处理方式预期的用户研究。

• 依赖来自用户代理的全局选择退出信号。

• 推迟同意提示，直到用户执行了某项使 请求具有上下文的操作， 这也有助于他们作出知情响应。

一个人可能会分享有关其他人的数据（例如一张同时包含这个人和其他人的照片）。如果 这个人同意处理该数据，这并不意味着其他人也 已经同意。

通知和其他打断式 UI 可以成为吸引注意力的有力方式。 根据所使用的操作系统，通知可能出现在 浏览器上下文之外（例如通用通知托盘中），甚至可能使设备 振动或播放提示音。 与所有强大功能一样，通知可能被滥用并成为滋扰， 甚至被用于操纵行为，从而降低自主性。

人们应可以自由限制其共享的私密信息量， 请求参与者限制对已共享数据的使用， 或请求删除数据。 当一个人选择拒绝或撤回使用其 数据的许可时， 进行报复是不适当的。

当服务运行所必需的数据被拒绝提供时，终止服务并不属于报复。 但是，如果拒绝提供数据 导致与使用该数据无关的行动， 则可能构成报复。 报复行为的示例包括：

• 使撤回同意的过程比给予同意更加繁琐；

• 使用威胁、纠缠或欺骗手段（[dark-patterns]） 促使人们重新考虑其选择；以及，

• 拒绝提供并不依赖使用这些数据的服务。

参与者可以投入时间和精力，将从人们那里收集数据的方式自动化，并可以 以使人们披露 信息比不披露容易得多的方式设计其产品，而 人们通常不得不手动应对各种选项、重复 提示和欺骗性模式。在许多 情况下，数据的缺失——即一个人拒绝提供某些信息—— 本身也可能具有识别性 或透露信息。此外，API 可以以僵化的方式定义或实现，从而阻止人们 访问有用的功能。例如，我可能想查找自己将在 本周末访问的某个城市中的餐馆，但如果我的地理位置被强制设置为与 GPS 匹配，餐馆查找 站点可能只允许搜索我当前位置附近的餐馆。在其他情况下，站点并不遵守数据 最小化原则，并请求超出其需要的信息。该原则支持 人们最大限度减少自己的数据。

用户代理应使 人们能够轻松地呈现他们 希望呈现的身份，并以 由他们控制的方式提供有关自身或其设备的信息。这有助于人们保持隐匿（[Lost-In-Crowd]， [Obscurity-By-Design]），包括通过混淆 有关自身的信息（[Obfuscation]）。

相反，API 可以表明一个人的偏好、一个人选择的身份、一个 人的查询或兴趣，或者一个人选择的沟通风格。

站点应在威胁建模中考虑欺骗，并且不应假定 Web 平台 API 对有关用户的信息的一致性、时效性或正确性提供任何保证。人们通常 控制自己用于与网站交互的设备和软件。响应站点 请求时，人们可能出于各种原因任意修改或选择其提供的信息， 其中既包括恶意目的，也包括自我保护。

在极少数必须将 API 定义为返回真实当前值的情况下，用户仍然可以 配置其代理以其他信息响应，原因包括测试、审计或 缓解各种形式的数据收集，包括浏览器 指纹识别。