要約

  • RFC 3693はTarget、Rule Maker、Rule Holder、Generator、Server、Recipient、Viewerを分け、位置の開示を単なる二者間の受け渡しとして扱わなかった。
  • 位置オブジェクトはプライバシールールを運べたが、すべてのオブジェクトへの格納は必須ではなく、ルール管理全体も定義されなかった。

座標が答えるのは「どこか」だ。誰が位置を測ったのか、誰の位置なのか、誰がどの精度で見られるのか、受け手が保存や転送をしてよいのかまでは示さない。GEOPRIVが明らかにしようとしたのは、まさにその欠けた動詞だった。

RFC 3693は2004年2月に Informational 文書として発行された。位置サービスを複数の役割に分解する。Target は位置を伝えられる人物または主体。Rule Maker はアクセスルールを作る主体で、多くの場合Target自身だが、常にそうとは限らない。文書は親や雇用主が他者のルールを作る例も挙げる。Rule Holder はルールを保管して渡す。Location Generator は位置を取得してオブジェクトを作り、Location Server はそれを受け取り、ルールを適用して許可された結果を配布する。Location Recipient は情報を受け取り、Viewer は転送せずに利用する。Data Transporter は内容を処理せず転送する。ひとつの機器が複数の役割を担うこともある。

この区別が重要なのは、プライバシーが暗号化だけでなく関係性に依存するからだ。ある資格情報を持つ相手には市区町村までの粗い位置を開示し、より精密な位置は伏せる、といったルールが考えられる。RFCは収集、利用、開示、保持を別々のルール対象として扱い、リンクされない仮名やプライバシー強化型資格情報にも対応するよう求めた。誰が位置情報を受け取ったかも、Targetの行動や関係を明かしうる。

位置オブジェクトは座標以上の情報を運べる設計だったが、それだけでルールを強制するトークンになるわけではない。RFC 3693は第三者によるルール適用を可能にするよう要求し、限定された中核ルールを格納できるべきだとした。しかし定義上は、位置情報と「場合によっては」プライバシールールを含むオブジェクトであり、毎回ルールを埋め込む必要はない。Serverの開示判断はRule Makerのルールに基づくべきであり、全ルールを知らないGeneratorもその指示に従わなければならない。Viewerに渡すのは適切な処理に必要な範囲だけとされた。

限界も明記されている。ルールをどう管理し、Serverがどう取得するかは対象外。ルール言語の表現力も未確定だった。保持期間の制約は技術的な帰結が曖昧な場合があり、地域の法制度や慣習に左右されることもある。ルールの認証と保護は求めたが、鍵の配布方法は定めなかった。位置オブジェクトを守っても、他のヘッダーや通信量の分析まで防げるわけではない。

後続文書は仕様化の進展を示すが、普及の証拠ではない。RFC 4119はPIDFを使う位置オブジェクト形式を定め、RFC 4079はプレゼンスの構成を説明した。2011年にBCP 160として出たRFC 6280はRFC 3693と3694を更新し、より広いアーキテクチャを提示した。HELD、SIPでの位置伝達、位置URIの参照解除も、取得・搬送・参照の具体的方法を後から定めている。

歴史的な成果は「インターネットが位置プライバシーを解決した」という話ではない。RFC 3693は制御面を見える形にした。誰が測位され、誰がルールを書き、どこに保存し、誰が適用し、どの精度を出し、受け手が次に何をできるのか。要件文書は境界を名付けられるが、サービスが実装したこと、受け手が従ったこと、個人が匿名のままだったことまでは証明しない。

参照資料