85
45

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【JavaScript】おおよその位置情報を取得できるようにしようという提案

Last updated at Posted at 2025-09-08

現在、JavaScriptで位置情報APIを使用すると、周囲の環境や引数にもよりますがメートル単位で正確な値を取得することができます。
つまり、自宅や職場や通勤通学路やその他入り浸っている宗教病院風俗など全てを正確に把握されてしまうということです。

しかし天気予報など、そこまでの精度は必要なく数キロ数十キロ単位でだいたいの位置さえ分かれば十分なサービスも数多くあります。
そういったサービスに不必要に正確な個人情報を与えることなく、しかし有用な程度に位置情報を与える方法はないでしょうか。

ということで、現在の正確な位置情報よりは安全性の高いおおよその位置情報を取得する方法を提供しようという提案がなされました。
以下は該当のproposal、Approximate Geolocationの概要です。

ちなみにもちろん提案はGoogleですが、珍しくプライバシーを考慮した提案となっています。
たぶん正確な位置情報を許可している人が想定より少なかったんでしょう。

Approximate Geolocation Explainer

Geolocation APIに、おおよその位置情報を追加する提案。

Motivation

正確な位置情報を共有すると、自宅の住所や職場、宗教施設などユーザの私生活に関する機密情報が漏洩する可能性があります。
しかしユーザは同時に、ローカライズや売買などのために位置情報を共有したいと考えるかもしれません。
郵便番号程度のおおよその位置情報であればプライバシーへのリスクは低く、そして大半のアプリにとってはその程度の精度で十分です。
Geolocation APIを拡張しておおよその位置情報をサポートすることで、ユーザは位置情報というプライバシーを確保し、Webサイト側は安全性の高い位置情報を要求できるようになります。

また一部地域では正確な位置情報を取得することが法律で禁じられており、その『正確』は最大半径によって決められています。
Webブラウザは、これらの要件を満たすおおよその位置情報APIをサポートすることで、コンプライアンスを守ることができます。

カリフォルニア州では、正確な位置情報の半径精度の定義は1850フィート・564メートルです。
コネチカット州では、正確な位置情報の半径精度の定義は1750フィート・533メートルです。
ユタ州では、正確な位置情報の半径精度の定義は1750フィート・533メートルです。
バージニア州では、正確な位置情報の半径精度の定義は1750フィート・533メートルです。

モバイルOSは既に、おおよその位置情報をユーザが制御できる機能を提供しています。

iOSは14で「正確な位置情報」設定が導入されました。
これをオフにするとおおよその位置情報が送信されます。
精度は現在地の人口密度に基いて決まり、おおよそ2キロメートルから10キロメートルの精度です。

Androidは12でおおよその位置情報と正確な位置情報の権限を与えることができるようなりました。
おおその位置情報は最低2キロメートルの精度です。

Proposal

このproposalでは、おおよその位置情報と正確な位置情報の概念を導入します。
正確な位置情報とは、精度半径が一定値以下である位置情報を表します。
このproposalでは少なくとも2キロメートルの境界を推奨します。

新しい権限『おおよその位置情報』が導入されます。
既に存在する『位置情報』権限は、『正確な位置情報』となります。
Webサイトは、『おおよその位置情報』『正確な位置情報』いずれかの権限を持っている場合に位置情報にアクセス可能です。

『おおよその位置情報』の許可プロンプトのUIについては、このproposalでは規定しません。
ユーザエージェントは『おおよその位置情報』『正確な位置情報』いずれかを選択できるようにすることが求められます。

ブラウザは、システムが『おおよその位置情報』機能を提供する場合はそちらを優先的に利用します。
正確な位置情報を使用する場合は粗雑化アルゴリズムを用いて変換します。
粗雑化アルゴリズムは、逆算して正確な位置情報を推測できないようにする必要があります。

粗雑化アルゴリズムの例としては、Androidプラットフォームの位置情報APIで使用されるLocationFudgerをご覧ください。
このアルゴリズムではsnap-to-gridとランダムオフセットという2つの手法を利用します。
snap-to-gridは、正確な位置情報とおおよその位置情報について多対一のマッピングを生成します。
ランダムオフセットは、グリッド境界を越えた際に正確な位置情報を推測できないようにします。

getCurrentPositionおよびwatchPositionを呼びだす際に、おおよその位置情報を要求するパラメータを追加することができます。

Example

navigator.geolocation.getCurrentPosition(
    onsuccess, onerror, {accuracyMode: 'approximate'});

Potential specification changes

潜在的な仕様変更。

Introduction

正確な位置情報とおおよその位置情報の概念の紹介と、正確な位置情報の精度について。

PositionOptions dictionary

PositionOptionsを、getCurrentPositionおよびwatchPositionのパラメータとして渡すことができます。

dictionary PositionOptions {
  boolean enableHighAccuracy = false;
  [Clamp] unsigned long timeout = 0xFFFFFFFF;
  [Clamp] unsigned long maximumAge = 0;

  // 追加
  AccuracyMode accuracyMode = "precise";
};

enum AccuracyMode {
  // 正確な位置情報
  "precise",

  // おおよその位置情報
  "approximate"
}

PositionOptionsにメンバーaccuracyModeが追加されます。
呼び出す際に、おおよその位置情報を要求する際は値approximateを、正確な位置情報を要求する際は値preciseを渡します。
互換のため、accuracyModeを渡さない場合はデフォルト値としてpreciseが使用されます。

Exposing Accuracy Level in GeolocationPosition

開発者が位置情報の精度情報を受け取るため、インターフェイスGeolocationPositionに属性accuracyModeを追加します。
これにより、Webサイトは位置情報が正確な位置情報なのかおおよその位置情報なのかを判断することができます。
正確な位置情報を要求したのにおおよその位置情報しか許可されなかった場合などに有用です。

[Exposed=Window, SecureContext]
interface GeolocationPosition {
  readonly attribute GeolocationCoordinates coords;
  readonly attribute EpochTimeStamp timestamp;

  // 追加
  readonly attribute AccuracyMode accuracyMode;

  [Default] object toJSON();
};

Capability detection

おおよその位置情報がサポートされているかは、次のコードで検出できます。

function browserImplementsAccuracyMode() {
  try {
    navigator.geolocation.getCurrentPosition(
      () => {},
      () => {},
      {
        get accuracyMode() { throw new Error('1'); },
        get enableHighAccuracy() { throw new Error('2'); }
      }
    );
  } catch (e) {
    if (e.message === '1') {
      return true;
    }
    console.assert(e.message === '2');
    return false;
  }
  console.assert(false, 'ここには到達しない');
}

Permissions

現在の位置情報パーミッションgeolocationに加え、おおよその位置情報パーミッションgeolocation-approximateを定義します。

geolocationを許可すると、geolocation-approximateも自動的に許可されます。
geolocation-approximateを拒否すると、geolocationも自動的に拒否されます。

言い換えると、ユーザがおおよその位置情報を拒否したら、正確な位置情報へのアクセスも拒否されます。
ユーザが正確な位置情報を許可したら、おおよその位置情報へのアクセスも許可されます。

考えられる許可状態と遷移によるPermissions.query()の動作については、こちらの分析を参照してください。

Permissions policy

Webサイトが位置情報を要求し、パラメータがaccuracyMode="approximate"でない場合、ユーザは正確な位置情報とおおよその位置情報のいずれかを選択するよう求められます。
Webサイトが位置情報を要求し、パラメータがaccuracyMode="approximate"である場合、ユーザはおおよその位置情報を求められます。
既におおよその位置情報を許可されている状態で正確な位置情報を要求した場合、ユーザは正確な位置情報を求められます。

感想

ということで、数キロメートル単位の誤差を含んだ位置情報を返すことで、リアルバレを防ぎつつ位置情報サービスも使用可能になります。
これによって、下手に特定されたりする可能性をほぼなくすることができるでしょう。

しかし『正確な位置情報』をわざわざ拒否しておきながら『おおよその位置情報』だけ許可する人なんてどれくらいいるんだろうか?

ところでスマホの『おおよその位置情報』、あれ何回も連打したら自身を中心とした範囲にプロットされるわけだから結局『正確な位置情報』がわかってしまうのでは?と前から思ってるんだけど、proposalによればsnap-to-gridとランダムオフセットで対策されているみたいですね。
まあ私が考える程度のことくらいさすがに対策されているか。

でも具体的にどういう処理なのかよくわからないので、結局最終的な出力はどうなるんだろう?
実際に連打してどうなるか試してみた的な記事くらいあるのではないかと探してみたんですけど意外と見当たりませんでした。

85
45
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
85
45

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?