摘要

  • RFC 3693 分别命名目标、规则制定者、规则持有者、位置生成器、位置服务器、接收方与查看者，不把披露简化成两方交换。
  • 位置对象可以携带隐私规则，但标准没有要求每个对象都内嵌规则，也没有定义完整的规则管理系统。

一组坐标只能回答“在哪里”。它没有说明是谁提供坐标、描述的是谁、谁可以看到、精度应到哪一级、接收方能否保存或转发。这些缺失的动作关系，正是 GEOPRIV 想要显露出来的问题。

RFC 3693 于 2004 年 2 月以 Informational 文件发布。它用不同角色描绘位置服务：Target 是被定位的人或实体；Rule Maker 制定访问规则，通常是 Target，但不一定——文中也举出父母或雇主代为制定规则的情形。Rule Holder 保存并提供规则；Location Generator 获取位置并创建对象；Location Server 接收对象、应用规则并分发允许披露的结果；Location Recipient 接收信息；Viewer 查看信息但不再转发。另有 Data Transporter 只负责传送、不处理内容。一个设备可以同时承担多个角色。

这样的区分很关键，因为隐私取决于关系，而不只是加密。一条规则可以允许持有某类凭证的人知道某人所在的城市，却不让他看到更精确的位置。RFC 3693 将收集、使用、披露和保留视为不同的规则对象，也要求支持不可关联的假名和增强隐私的凭证。谁收到了位置，本身也可能暴露 Target 的习惯或关系网络。

位置对象因此不只是坐标容器，却也不是自动执行政策的令牌。RFC 3693 要求对象能够支持第三方执行规则，并提出对象应能携带一组有限的核心规则；但它把对象定义为承载位置数据，“也可能”承载隐私规则，并未要求每个实例都内嵌规则。服务器是否向接收方披露位置，应依据 Rule Maker 制定的规则。即便生成器看不到完整规则，也必须遵从制定者的指示；查看者则只应得到合规处理所需的规则子集。

文件也明确标出了边界：规则如何管理、服务器如何取得规则，都不在 RFC 3693 的范围内。规则语言的表达能力没有定稿。保留期限之类的规则，其技术后果可能含糊，也可能受当地法律或习惯影响。文件要求规则得到认证和保护，却没有规定密钥如何分发、机制如何实现。即便位置对象本身受到保护，其他报头和对象仍可能遭受流量分析。

后来的文件显示的是规范工作继续推进，并非普遍部署的证明。RFC 4119 定义了基于 PIDF 的位置对象格式，RFC 4079 描述呈现架构。2011 年，作为 BCP 160 发布的 RFC 6280 更新 RFC 3693 与 RFC 3694，并将要求扩展为更完整的架构。HELD、SIP 位置传送和位置 URI 解析随后分别规定了获取、传递或取回位置的具体方式。

这段历史的成果，远小于“互联网解决了位置隐私”。RFC 3693 让控制链条变得可见：谁被定位、谁写规则、规则存放在哪里、谁来执行、披露到什么精度，以及接收方之后可以做什么。要求文件能够命名边界，却不能证明某项服务真正实现了它、接收方遵守了它，或当事人保持了匿名。

来源