地図が居場所を知りたがった。ブラウザーは先に本人に聞いた

Summary

• W3Cは2008年12月22日にGeolocation APIの最初の公開草案を出し、GPSなど特定の測位方法に縛られず、端末の位置をスクリプトから求める窓口を示した。
• 2013年10月24日の勧告は、一度の取得、継続的な更新、精度、キャッシュと利用者の明示的な許可を定めた。2016年の第二版は2013年版の訂正を取り込んだ。

旅人は交差点で紙の地図を逆さまに持っている。路面電車の停留所は近いはずなのに、川の位置が頭の中と合わない。ウェブ地図なら青い点を置いて話を終わらせられる。ただし、その点は旅人の居場所という、ずいぶん個人的な情報でできている。ページが欲しいと言うだけで手渡してよい品物ではない。

2008年12月22日の最初の公開草案は、ブラウザーを介して端末に結び付いた位置情報をスクリプトへ渡す高水準のAPIを描いた。見知らぬ街で観光先を探す人や、地図上で現在地を確かめる人が例に登場する。ページが使うのは緯度、経度と精度であり、端末の中でどの部品が働いたかの報告書ではなかった。

測位の出所は一つに決めなかった。GPSのほか、IPアドレス、Wi-Fi、携帯電話網などの手掛かりも想定された。端末とブラウザーが使える材料で位置を見積もり、サイトは共通の形で答えを受け取る。これなら案内サービスは機種ごとの測位装置を知り尽くさなくてよい。一方、地図の点は万能の目撃証言ではない。精度の値と一緒に読んで初めて、どの範囲を示しているかが分かる。

質問の仕方も分かれていた。getCurrentPosition()は一度だけ位置を求める。watchPosition()は移動に合わせて更新を受け取り、clearWatch()でその監視を止める。近くの喫茶店を探すのと、街を歩く間ずっと道順を更新するのとでは、位置が必要な時間が違う。2009年7月7日の最終意見募集草案は、こうした設計とプライバシーの論点をさらに進めた。W3Cの刊行履歴を見れば、2008年の最初の草案から2013年の勧告まで時間がかかったことも分かる。

2013年10月24日の勧告は、位置を渡す窓口をはっきり定めた。利用者の明示的な許可なしにブラウザーがサイトへ位置を送ってはならない。通常のブラウザーでは許可画面に要求元のホスト名を示す。セッションを越えて保存する許可は取り消せなければならない。拒否されたらPERMISSION_DENIEDとして扱う。地図は質問できるが、返事を当然の権利として受け取るわけではない。

要求には鮮度や待ち時間の指定もある。maximumAgeはキャッシュにある位置をどこまで古くても受け入れるか、timeoutは新しい測位をどれだけ待つかを示す。enableHighAccuracyは高い精度を望むという合図で、達成の保証ではない。より長い待ち時間や電力消費を伴うこともある。許可を考える人間の時間は、測位のタイムアウトに含めない。急ぐアプリにも、旅人が質問を読む時間は残された。

位置の答えにはメートル単位のaccuracyが付く。勧告は精度値が95パーセントの信頼水準に相当するべきだとした。地図の青い点は、ひとつの舗石を指す針というより、あり得る位置の円として扱うほうが正直だ。勧告は実際の端末位置が必ず得られるとも約束していない。おおよその場所が分かれば街歩きには十分でも、画面が勝手に確信を強めてよい理由にはならない。

受け取った後の扱いも別の判断である。2013年の文書は、必要なときに位置を求め、示した目的に使い、仕事が終われば明示的な保存許可がない限り処分し、再送するなら改めて明示的な許可を得るよう受領者に求めた。停留所を探すことと、移動履歴をずっと残すことは同じ座標から始まる。利用者が頼んだ仕事は同じではない。

2016年の第二版は2013年勧告の誤りを直した編集版だった。位置を巡る基本の分担は続く。端末とブラウザーが推定方法を選び、本人が最初の受け渡しを選び、サイトは受け取った情報の使い道に責任を持つ。共通APIは、地図も天気も街案内も使える一つの質問の形を作った。

街角の旅人には、その仕組みが長い標準文書に見える必要はない。地図が便利に使える一方、居場所を尋ねる相手の名前を見て答えを決められればよい。紙の地図をまだ逆さまに持っていても、ブラウザーは勝手に指を差す前に一声かけるようになった。