<前の日記(2007年11月03日) 次の日記(2007年11月05日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 841   昨日: 1668

2007年11月04日

最終回: PlaceEngineの次に来るもの そしてRFIDタグの普及する未来

この日記を書き始めたいきさつは、2003年の春、RFIDタグのプライバシー問題について、何が問題なのかあまりに理解されないことに危機感を覚え、ひとつひとつ書いていこうと決意したことからだった。

当時いろいろな方とお話しした中で最も印象に残っているのは、日経デジタルコアのイベントの宴席の2次会で同じテーブルについてお話しする機会のあった泉田氏との議論だった。そのときのことは2003年7月4日の日記に記録がある。その泉田氏は現在の新潟県知事である。

泉田氏はこうおっしゃった。「プライバシーが問題になるとしたら、政府がRFID読み取り網を整備するようなことになったとき。そうでなければ無理。」

つまり、街中にRFID読み取り機が設置され、そしてそれがネットワークに接続されるような状況は、国などが敷設しない限りありえない話だということだった。たとえば、警察が Nシステムと同様の目的で RFID監視網を設置するような状況などが考えられ、他にそういう需要がないという話になった。

それに対し私は、民間が、たとえばコンビニ店とかが、それぞれの必要性で設置したRFID読み取り機が、全体として繋ぎ合わされることによる脅威があるので……とか、街中にと言っても、300メートルおきである必要はなく、数キロ間隔であってもプライバシーの問題にはなるので……ということを言った記憶がある。

あれから4年。PlaceEngineが実用化され、付加サービスも開始され、着々と既成事実化されようとしている。

現在のPlaceEngineは、観測される無線LAN信号のうち、アクセスポイントが発するビーコン信号だけを選別して用いている。これは、PlaceEngineの目的が位置を測定することにあるため、移動することの少ないアクセスポイントの電波を頼りにしているからである。無線LANのクライアント側デバイスは通常、移動することが多いと考えられる(ノートPCや、携帯ゲーム機、iPod等)ため、それらが発する信号はPlaceEngineにとっては無用なものとなっている。

しかし、技術上、ビーコン信号以外の無線LANパケットを活用することも可能だ。つまり、無線LANクライアント側のMACアドレスを活用した、何らかの新たな「ユビキタス」システム/サービスが登場することが考えられる。

昨日の日記の図1でも示したように、無線LANデバイスは、常時、周囲で通信中の無線LAN機器のMACアドレスを受信している。PlaceEngineがそうしているように(図1)専用のネットワークドライバをインストールすれば、こうしたクライアント側デバイスのMACアドレスを取得して活用するソフトウェアを作ることができるだろう。

図1: PlaceEngineがインストールするネットワークドライバ

ただし、さすがに、他人の通信に係るデータパケットを傍受してそのMACアドレスを勝手に使えば、電波法59条に違反すると思われる。PlaceEngineが合法かもしれないのは、送信先MACアドレスが「FF:FF:FF:FF:FF:FF」のブロードキャスト信号であるビーコン(図2)だけを使っているからだろう。

図2: ビーコン信号の例

しかし、実は、無線LANクライアントもブロードキャスト信号を発信している。図3のように、Windows XP の無線LANクライアントは、数十秒間隔で「probe request」と呼ばれる信号をブロードキャスト送信している。

図3: probe request信号の例

図3の送信元「00:16:6F:3X:XX:XX」(「00:16:6F」はベンダIDであるため上部では「Intel」と表示されている)は、私のノートPCの無線LANデバイスのMACアドレスである。このヘッダと共に「SSID: GoogleWiFi」という情報を掲載したprobe request信号がブロードキャストされている。

これは何のために発信されているのかというと、SSIDが「GoogleWiFi」であるアクセスポイントがないか周囲に問い合わせているものだ。もし周囲に、SSIDが「GoogleWiFi」と設定されたアクセスポイントがあれば、そのアクセスポイントがprobe response信号をそのMACアドレスに向けて返すようになっている。*1

この信号を傍受して活用すれば、巷に出回っている各種の無線LANクライアントが、どのように街を移動しているかの情報を蓄積するデータベースを構築することができるだろう。

そうなると、個人の移動履歴を勝手に構築されることにもなり得る。

このことは、RFIDタグのプライバシー問題を懸念していたのと同じことであるわけだが、4年前の私も、これほどまでに簡単にそれが実現し得るとは予想できなかった。というのは、当時の発想では、RFIDタグの読み取り機は固定的に街に設置する必要があると思い込んでいたからだ。その場合、各読み取り機をインターネットに接続してとなると大掛かりであり、誰がそこまでするのかという疑問(泉田氏が言っていたように)があった。携帯電話にRFIDリーダが搭載された場合では、携帯電話は移動しているので、それと同時にGPSで位置も測定しないと、そのRFIDタグがどこに存在したかの記録にならない。そういうことはあまり現実的でないと思っていた。

だが、どうだろう。PlaceEngineが普及しつつある現在、無線LAN搭載機器は、周囲の他の無線LAN搭載機器のprobe request信号の傍受によりそれらの存在を知得するのと同時に、周囲のアクセスポイントからの電波を元にしたPlaceEngineによる位置検索で、現在地を知得できてしまう。

このままラーメンレーダーのようなサービスが普及して、たくさんの人が街で常時、位置情報をと周辺の無線LAN機器の存在を記録(ないしサーバ送信)するようになってくると、他の無線LAN機器を持ち歩いている人々の移動履歴も蓄積されるようになる。

ここで注意したいのは、PlaceEngineの利用者(利用規約に同意している)以外の人たちも、その移動履歴が記録されてしまう点である。また、その移動履歴の記録は、PlaceEngine以外のサービスによって行われる可能性がある。(PlaceEngineと別のシステムが同時にインストールされた無線LAN機器が普及した場合。)

はたして、私達の社会は、そういう未来を受け入れるのだろうか。

勝手に他人の電波を傍受して利用するのは、電波法59条の趣旨にに照らしてどうか。PlaceEngineが合法であるとすれば、無線LANのビーコン信号はそれがブロードキャスト信号である(皆に向けて送信される「放送」である)という理由で、電波法59条の「特定の相手方に対して行われる無線通信」に当たらないと解釈できた場合であろう。その理屈が通るなら、無線LANクライアントのprobe request信号も、ブロードキャストであるから、それを傍受して勝手に利用するのは合法ということになってしまう。本当にそれでよいのだろうか?

ネットワークの低レイヤーにおいて技術上はブロードキャストになっていても、それによって実現する高レイヤーのネットワークは特定の相手との通信であるし、またそれを使用するユーザの意図としても、特定の相手と通信するためのものであることから、ビーコンやprobe request信号は「特定の相手方に対して行われる無線通信」の一部であるとする解釈もあり得よう。

さらに、数年〜10年後、RFIDタグが人々の持ち物に内蔵されるようになり、RFIDリーダ搭載の無線LAN機器が普及した暁にはどうなるか。周囲のRFIDタグのIDを読み取りながら、PlaceEngineで位置を測定して、それらを蓄積するというソフトウェアが普及してしまうかもしれない。2004年10月10日の日記にも書いていたが、他人のRFIDタグのIDを勝手に読み取る行為の電波法59条での扱いもどうなのか。

そろそろこのことについてはっきりさせておかないと、後戻りできなくなってしまうのではないだろうか。

*1 このように、アクセスポイント側でステルス機能でSSIDを隠していても、クライアント側がSSIDを送ってくるので、隠しても無駄である。


<前の日記(2007年11月03日) 次の日記(2007年11月05日)> 最新 編集

最近のタイトル

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
<前の日記(2007年11月03日) 次の日記(2007年11月05日)> 最新 編集