高木浩光＠自宅の日記

■ Bluetoothで山手線の乗降パターンを追跡してみた

この日記を書き始めてからもう6年になろうとしている。書き始めたきっかけは、RFIDタグのプライバシー問題が理解されないことに焦りを感じたからだった。当時の空気では、RFIDタグは5年後くらいに普及し、しだいにRFIDの埋め込まれた日用品で溢れかえるようになり、10年後くらいにプライバシー問題が顕在化すると目されていた。しかし、6年経った現在、私の靴にRFIDタグは埋め込まれていない。

当時の議論で描かれていたRFIDタグの問題は、無線LANやBluetoothにも共通することであり（MACアドレスがユニークIDとなる）、それらの方が先に普及するかもしれないという予感はあったが、現時点でも、無線LAN機器を持ち歩いている人はごく一部の人に限られている。しかし、Bluetoothはどうだろうか。これまでにも何度か、最近のBluetooth事情について書こうとしたことがあったが、他のネタで精一杯で先送りにしていた。

最近のBluetooth事情

図1は、2008年6月に電車内でBluetooth機器を設定をしようとしたときの様子である。

図1: 周辺のBluetooth機器を探査している様子

かなりの数の携帯電話がBluetooth機器として検出されている。走行中の列車内で5人前後が検出され、駅に到着すると20人前後がドカドカっと検出される（ホームに立っている人の携帯電話が次々に検出される）という感じだった。一昨年あたりから急速にBluetooth対応携帯電話が普及しているようだ。

Bluetoothの機器探査（device inquiry）では、最初に周辺機器からMACアドレスを得て、次に各MACアドレスの機器に名前の問い合わせをするプロトコルになっている。図1にも一部見えているように、Mac OS XのBluetooth機器設定の画面では、名前解決前のMACアドレスがそのまま表示される。

Bluetoothでは、Bluetooth機能をオンにしていても、探査可能（検出可能）に設定していなければ、このように見つけられてしまうことはないのだが、意外にも、探査可能設定でBluetoothをオンにしたままの人がかなりの割合でいるようだ。これは、RFIDタグよりも先にBluetoothによって、IDのプライバシー問題が顕在化しそうな勢いである。

そこで、実際にいかほどのことが可能なのかを調べるため、Bluetooth機器探査の応答をログに記録するプログラムを作成して、山手線を4周してきた。

図2: JR東日本の「都区内パス」

機器探査ログ

2009年3月1日の日曜日、池袋駅18:12発の外回り列車に乗り、真ん中あたりの車両の中央の座席に腰掛け、観測を開始。4周廻って池袋駅22:18着まで*1を観測した。その間に1154個のMACアドレスを検出した。

観測データは以下のように記録した（MACアドレスの下位24ビットは伏せている*2）。約21秒ごとの時間スロットに区切って機器探査を繰り返し行い、新たに見つかったMACアドレスを「+」のマークで示している（「#」は私の鞄の中のスマートフォンのアドレス）。

最初の時間スロットは池袋駅停車中であり、2つ目のスロットは駅から動き出した時、3つ目のスロットは、駅を離れて走行中の時である。3つ目から5つ目までのスロットで、7つのMACアドレスを継続して検出していることから、大塚駅までの区間で、私以外に6人の人がBluetooth機器を（検出可能設定のままオンにして）持っていたことを意味している。それに対して、1つ目のスロットや2つ目のスロットで検出されたのに3つ目以降で現れていない（ごく短い時間だけ現れた）MACアドレスが多数あるが、これは、駅のホームを歩いている人のMACアドレスを検出したものと考えられる。

2009-03-01.18:12:03 001CEEXXXXXX +
2009-03-01.18:12:04 001987XXXXXX +
2009-03-01.18:12:05 00175CXXXXXX +
2009-03-01.18:12:06 001783XXXXXX # +
2009-03-01.18:12:07 00175CXXXXXX +
2009-03-01.18:12:08 001A16XXXXXX +
2009-03-01.18:12:09 001CEEXXXXXX +
2009-03-01.18:12:10 001C43XXXXXX +
2009-03-01.18:12:11 00175CXXXXXX +
2009-03-01.18:12:12 001C43XXXXXX +
2009-03-01.18:12:13 00175CXXXXXX +
2009-03-01.18:12:14 00175CXXXXXX +
2009-03-01.18:12:15 001CEEXXXXXX +
2009-03-01.18:12:16 001CEEXXXXXX +
2009-03-01.18:12:16 0018AFXXXXXX +
2009-03-01.18:12:16 0015B7XXXXXX +
2009-03-01.18:12:16 00175CXXXXXX +
2009-03-01.18:12:16 00175CXXXXXX +
2009-03-01.18:12:16 0000EBXXXXXX +
2009-03-01.18:12:16 0000EBXXXXXX +
2009-03-01.18:12:16 00175CXXXXXX +
#### 21 2009-03-01.18:12:16
2009-03-01.18:12:24 00175CXXXXXX
2009-03-01.18:12:25 00175CXXXXXX
2009-03-01.18:12:26 001C43XXXXXX
2009-03-01.18:12:27 001CEEXXXXXX
2009-03-01.18:12:28 00175CXXXXXX +
2009-03-01.18:12:29 0015B7XXXXXX
2009-03-01.18:12:30 001987XXXXXX
2009-03-01.18:12:31 001783XXXXXX #
2009-03-01.18:12:32 001CEEXXXXXX +
2009-03-01.18:12:33 00175CXXXXXX +
2009-03-01.18:12:34 0021D1XXXXXX +
2009-03-01.18:12:35 00175CXXXXXX +
2009-03-01.18:12:36 00175CXXXXXX +
2009-03-01.18:12:37 00175CXXXXXX +
2009-03-01.18:12:37 00175CXXXXXX +
2009-03-01.18:12:37 001987XXXXXX +
2009-03-01.18:12:37 00175CXXXXXX +
2009-03-01.18:12:37 002265XXXXXX +
#### 18 2009-03-01.18:12:37
2009-03-01.18:12:45 001C43XXXXXX
2009-03-01.18:12:46 001CEEXXXXXX
2009-03-01.18:12:47 00175CXXXXXX
2009-03-01.18:12:48 001783XXXXXX #
2009-03-01.18:12:49 001987XXXXXX
2009-03-01.18:12:50 00175CXXXXXX
2009-03-01.18:12:51 0015B7XXXXXX
#### 7 2009-03-01.18:12:58
2009-03-01.18:13:06 00175CXXXXXX
2009-03-01.18:13:07 001CEEXXXXXX
2009-03-01.18:13:08 001C43XXXXXX
2009-03-01.18:13:09 0015B7XXXXXX
2009-03-01.18:13:10 001987XXXXXX
2009-03-01.18:13:11 001783XXXXXX #
2009-03-01.18:13:12 00175CXXXXXX
2009-03-01.18:13:13 00175CXXXXXX
#### 8 2009-03-01.18:13:19
2009-03-01.18:13:27 001CEEXXXXXX
2009-03-01.18:13:28 0015B7XXXXXX
2009-03-01.18:13:29 001C43XXXXXX
2009-03-01.18:13:30 00175CXXXXXX
2009-03-01.18:13:31 001783XXXXXX #
2009-03-01.18:13:32 001987XXXXXX
2009-03-01.18:13:35 00175CXXXXXX
#### 7 2009-03-01.18:13:41
2009-03-01.18:13:48 00175CXXXXXX
2009-03-01.18:13:49 001CEEXXXXXX
2009-03-01.18:13:50 001C43XXXXXX
2009-03-01.18:13:51 001CEEXXXXXX +
2009-03-01.18:13:52 0015B7XXXXXX
2009-03-01.18:13:53 001987XXXXXX
2009-03-01.18:13:54 001783XXXXXX #
2009-03-01.18:13:55 00175CXXXXXX +
2009-03-01.18:13:56 00175CXXXXXX
2009-03-01.18:14:01 00175CXXXXXX
#### 10 2009-03-01.18:14:02
2009-03-01.18:14:10 001C43XXXXXX
2009-03-01.18:14:11 001CEEXXXXXX
2009-03-01.18:14:12 0015B7XXXXXX
2009-03-01.18:14:13 00175CXXXXXX
2009-03-01.18:14:14 001CEEXXXXXX +
2009-03-01.18:14:15 00175CXXXXXX
2009-03-01.18:14:16 001987XXXXXX
2009-03-01.18:14:17 001CEEXXXXXX +
2009-03-01.18:14:18 001783XXXXXX #
#### 9 2009-03-01.18:14:23

6つ目と7つ目のスロットでは、大塚駅に到着して、「+」マークの新しいMACアドレスが現れている。

ログを眺めながら乗車していると、対向列車とすれ違ったときにも「+」が現れることがあった。また、京浜東北線と並走するときにも「+」が出ることがあった。

Bluetoothの通信距離は10メートルの規格と100メートルの規格があるが、おそらく携帯電話側が10メートルのものであろう。山手線の車両の長さが20メートルなので、ちょうど1両分の範囲で観測したことになる。

ただし、乗車人数に比例して増えるわけではなかった。以下は、ほぼ満員になったピーク時（渋谷駅22:03発、原宿までの区間）の様子である。私以外に13人ほどが継続して検出されている。このとき、駅に停車中でもホームの人をあまり捉えていないことから、着席していると人体で遮られて遠くの機器を検出できなくなるのではないかと思われる。

2009-03-01.22:03:15 00175CXXXXXX
2009-03-01.22:03:16 00175CXXXXXX
2009-03-01.22:03:17 00175CXXXXXX
2009-03-01.22:03:18 001783XXXXXX #
2009-03-01.22:03:19 00175CXXXXXX
2009-03-01.22:03:20 001CEEXXXXXX
2009-03-01.22:03:21 001CEEXXXXXX
2009-03-01.22:03:22 00175CXXXXXX
2009-03-01.22:03:23 001CEEXXXXXX
2009-03-01.22:03:24 00175CXXXXXX
2009-03-01.22:03:25 001CEEXXXXXX
2009-03-01.22:03:26 00175CXXXXXX
2009-03-01.22:03:27 0000EBXXXXXX
2009-03-01.22:03:28 080074XXXXXX
#### 14 2009-03-01.22:03:29
2009-03-01.22:03:37 0000EBXXXXXX
2009-03-01.22:03:38 00175CXXXXXX
2009-03-01.22:03:39 00175CXXXXXX
2009-03-01.22:03:40 00175CXXXXXX
2009-03-01.22:03:41 001CEEXXXXXX
2009-03-01.22:03:42 00175CXXXXXX
2009-03-01.22:03:43 001CEEXXXXXX
2009-03-01.22:03:44 00175CXXXXXX
2009-03-01.22:03:45 00175CXXXXXX
2009-03-01.22:03:46 00175CXXXXXX +
2009-03-01.22:03:47 00175CXXXXXX
2009-03-01.22:03:48 080074XXXXXX
2009-03-01.22:03:49 001CEEXXXXXX
2009-03-01.22:03:50 001CEEXXXXXX
2009-03-01.22:03:50 001783XXXXXX #
#### 15 2009-03-01.22:03:50
2009-03-01.22:03:58 001783XXXXXX #
2009-03-01.22:03:59 001CEEXXXXXX
2009-03-01.22:04:00 001CEEXXXXXX
2009-03-01.22:04:01 00175CXXXXXX
2009-03-01.22:04:02 001CEEXXXXXX
2009-03-01.22:04:03 00175CXXXXXX
2009-03-01.22:04:04 00175CXXXXXX
2009-03-01.22:04:05 00175CXXXXXX
2009-03-01.22:04:06 00175CXXXXXX
2009-03-01.22:04:07 00175CXXXXXX
2009-03-01.22:04:08 080074XXXXXX
2009-03-01.22:04:09 001CEEXXXXXX
2009-03-01.22:04:10 0000EBXXXXXX
2009-03-01.22:04:11 00175CXXXXXX
#### 14 2009-03-01.22:04:11
2009-03-01.22:04:19 00175CXXXXXX
2009-03-01.22:04:20 080074XXXXXX
2009-03-01.22:04:21 00175CXXXXXX
2009-03-01.22:04:22 00175CXXXXXX
2009-03-01.22:04:23 001CEEXXXXXX
2009-03-01.22:04:24 001CEEXXXXXX
2009-03-01.22:04:25 00175CXXXXXX
2009-03-01.22:04:26 0000EBXXXXXX
2009-03-01.22:04:27 00175CXXXXXX
2009-03-01.22:04:28 00175CXXXXXX
2009-03-01.22:04:29 001CEEXXXXXX
2009-03-01.22:04:30 001CEEXXXXXX
2009-03-01.22:04:31 00175CXXXXXX
2009-03-01.22:04:32 001783XXXXXX #
#### 14 2009-03-01.22:04:32
2009-03-01.22:04:40 001CEEXXXXXX
2009-03-01.22:04:41 001CEEXXXXXX
2009-03-01.22:04:42 00175CXXXXXX
2009-03-01.22:04:43 00175CXXXXXX
2009-03-01.22:04:44 00175CXXXXXX
2009-03-01.22:04:45 00175CXXXXXX
2009-03-01.22:04:46 0000EBXXXXXX
2009-03-01.22:04:47 080074XXXXXX
2009-03-01.22:04:48 001CEEXXXXXX
2009-03-01.22:04:49 00175CXXXXXX
2009-03-01.22:04:50 00175CXXXXXX
2009-03-01.22:04:51 00175CXXXXXX
2009-03-01.22:04:52 001783XXXXXX #
2009-03-01.22:04:53 001CEEXXXXXX
2009-03-01.22:04:53 001CEEXXXXXX +
2009-03-01.22:04:53 001C7EXXXXXX +
#### 16 2009-03-01.22:04:53

乗降パターン

さて、こうして検出した機器を、時刻に沿って同心円上に描いてみた。

図3: 山手線の乗降パターン

短い線分は1回だけ検出されたことを表している。黒と赤があるのは、（同じライン上に描いているけれども）別のMACアドレスであることを示している。（同じライン上に色が変わらずに飛び飛びに描かれているのは、同じMACアドレスのものである。）

短い線分がたくさん重なっているのは、駅のホームを歩く人などを通りすがりに続々と検出したもので、これの多いところのほとんどは駅である。

以下のJavaアプレットで、4周分を見ることができる。（クリックで開始。）

ログを分析してみると、約1時間間隔で繰り返し点として現れたMACアドレスが何個かあった。山手線は一周が1時間と数分なので、これは、駅に設置されている何らかの情報機器か、もしくは近接した住宅や事務所の情報機器なのかもしれない。以下にそれを示す。

00037AXXXXXX 187:12 | 42,43,216,217,402,573
001CEEXXXXXX 185:06 | 110,111,112,113,285,286,469,635
00037AXXXXXX 125:11 | 224,579
00175CXXXXXX 125:10 | 231,232,233,419,420,586
00175CXXXXXX 124:49 | 236,590
001C7EXXXXXX  66:00 | 138,309,323,324,325
00037AXXXXXX  63:07 | 93,94,95,96,268,269,270,271,272
00037AXXXXXX  61:24 | 149,150,151,322,323

左から2列目は、最初に検出されてから最後に検出されるまでの時間で、「|」の右側のコンマで区切られた数値は、時間スロットの番号（約21秒で区切られたスロットなので、1時間が約171スロット）で、検出された時間スロットのリストである。

約30分間隔で現れたものもあった。これは何だろうか。対向列車に乗車して半周した人、あるいは、対向列車の運転士や車掌さんなのだろうか。

001CD6XXXXXX  29:35 | 563,568,646,647
00175CXXXXXX  28:33 | 425,506

一方、不規則な間隔で現れたものもあった。以下の2つ目の事例の、50分後に現れたケースは、同じ人が対向列車か別ルートで駅に移動していたのを捕らえたものだろうか。1つ目の、90分後、8分後、20分後というのは解せない。3つ目以下の20分後に現れるというのも解せないが、これらは、同じ列車に継続して乗車していたものの距離が遠くて飛び飛びにしか検出されなかったケースなのかもしれない。

00236CXXXXXX 128:21 | 202,480,505,566
0023D6XXXXXX  50:02 | 84,85,226
001CEEXXXXXX  24:41 | 461,531
001CEEXXXXXX  24:19 | 461,530
001CEEXXXXXX  22:35 | 222,285,286
001CEEXXXXXX  19:45 | 619,621,675
00175CXXXXXX  16:13 | 461,507
00175CXXXXXX  15:49 | 129,174
001CEEXXXXXX  14:26 | 44,80,85

これらの例外的なケースを除き、継続して検出され、継続時間の長いものを列挙してみると次のようになる。半周以上する人はいないことがわかる。

001987XXXXXX 27:30 | 429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,505,506,507
001CEEXXXXXX 24:20 | 619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688
00175CXXXXXX 20:06 | 653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710
001EA4XXXXXX 20:04 | 564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,611,612,613,614,615,616,619,620,621
001CEEXXXXXX 19:25 | 182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237
00175CXXXXXX 19:20 | 94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149
00175CXXXXXX 19:02 | 619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673
001CEEXXXXXX 19:02 | 506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560
001FC4XXXXXX 19:02 | 452,453,454,455,456,457,458,459,460,461,462,463,465,466,467,468,469,474,475,476,477,478,479,480,481,482,483,486,488,496,497,501,506
0022F3XXXXXX 18:40 | 530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583
00175CXXXXXX 18:40 | 529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582
00175CXXXXXX 18:40 | 473,489,495,506,524,525,526
00175CXXXXXX 18:17 | 123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175
00175CXXXXXX 18:04 | 176,177,178,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227
00175CXXXXXX 17:58 | 383,388,392,397,413,424,425,427,429,434
0000EBXXXXXX 17:16 | 551,558,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,590,591,592,593,594,595,596,597,598,599,600
00175CXXXXXX 16:53 | 0,3,5,10,12,15,16,18,19,20,22,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,48
001CEEXXXXXX 16:32 | 545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592
001CEEXXXXXX 16:13 | 627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673
00175CXXXXXX 15:52 | 653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694,695,696,697,698
0000EBXXXXXX 15:30 | 487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531
00175CXXXXXX 15:11 | 242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285
001CD6XXXXXX 15:09 | 596,597,598,599,600,601,602,603,606,607,611,612,613,614,615,617,618,619,620,621,622,623,624,626,627,628,629,630,631,632,633,634,635,636,637,638,639
00175CXXXXXX 15:09 | 591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634
001C43XXXXXX 14:46 | 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42
0015B7XXXXXX 14:46 | 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42
00175CXXXXXX 14:04 | 123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163

継続して検出されたものから乗車時間の分布をグラフにしてみたところ、図4のようになった。

図4: 乗車時間の分布

偶然の乗り合わせ

この実験を決行する前に、予備テストとして、勤務先から帰宅する電車内で何回かこのプログラムを稼働させていた。具体的には、2月18日の24時04分からと、2月20日の23時16分から、2月24日の23時08分からで、ほぼ同じ車両に乗っていたと思う。

もしかすると同じ人を複数回検出しているかもしれないと思うわけだが、確率的にありそうもないと思ったのだが、実際に集計してみて驚いた。なんと、該当者を捕らえていたのだ。

2009-02-20.23:22:55 001CEEXXXXXX +
2009-02-20.23:25:25 001CEEXXXXXX
2009-02-20.23:25:51 001CEEXXXXXX
2009-02-20.23:26:04 001CEEXXXXXX
2009-02-20.23:27:27 001CEEXXXXXX
2009-02-20.23:29:02 001CEEXXXXXX
2009-02-20.23:31:03 001CEEXXXXXX
2009-02-20.23:31:20 001CEEXXXXXX
2009-02-20.23:32:45 001CEEXXXXXX

2009-02-24.22:59:58 001CEEXXXXXX +
2009-02-24.23:00:20 001CEEXXXXXX
2009-02-24.23:00:36 001CEEXXXXXX
2009-02-24.23:01:00 001CEEXXXXXX
2009-02-24.23:01:23 001CEEXXXXXX
2009-02-24.23:01:44 001CEEXXXXXX
2009-02-24.23:02:05 001CEEXXXXXX
2009-02-24.23:02:22 001CEEXXXXXX
2009-02-24.23:02:46 001CEEXXXXXX
2009-02-24.23:03:00 001CEEXXXXXX
2009-02-24.23:03:27 001CEEXXXXXX
2009-02-24.23:03:50 001CEEXXXXXX
2009-02-24.23:04:07 001CEEXXXXXX
2009-02-24.23:05:14 001CEEXXXXXX
2009-02-24.23:05:24 001CEEXXXXXX
2009-02-24.23:06:12 001CEEXXXXXX
2009-02-24.23:06:35 001CEEXXXXXX
2009-02-24.23:06:50 001CEEXXXXXX
2009-02-24.23:07:13 001CEEXXXXXX
2009-02-24.23:07:54 001CEEXXXXXX
2009-02-24.23:08:13 001CEEXXXXXX

たった3回計測しただけで、しかも時刻は同じではないのに、同じ車両に乗り合わせた人がいたことが判明してしまった。今まで、東京の電車に乗っていて、同じ人がいるなんて思ったことは一度もなかったのに……。

もうひとつある。出勤時にもテストしていたことがあり、具体的には、2月20日の13時06分からなのだが、18日の24時過ぎに継続して検出されていた人が、20日の昼間に1回だけ検出されている。これはいったい何だろうか。

2009-02-19.00:05:40 00175CXXXXXX
2009-02-19.00:06:01 00175CXXXXXX
2009-02-19.00:06:23 00175CXXXXXX
2009-02-19.00:06:48 00175CXXXXXX
2009-02-19.00:07:09 00175CXXXXXX
2009-02-19.00:07:29 00175CXXXXXX
2009-02-19.00:07:57 00175CXXXXXX
2009-02-19.00:08:13 00175CXXXXXX
2009-02-19.00:08:33 00175CXXXXXX
2009-02-19.00:08:56 00175CXXXXXX
2009-02-19.00:09:11 00175CXXXXXX
2009-02-19.00:09:40 00175CXXXXXX
2009-02-19.00:10:00 00175CXXXXXX
（略）

2009-02-20.13:07:16 00175CXXXXXX

この実験の適法性

このような他人のBluetooth機器を探査する行為に違法性はないのか、検討しておく必要がある。

類似の話として、一昨年、家庭の無線LANアクセスポイントのMACアドレスを収集して利用する「PlaceEngine」について、電波法59条違反のおそれがあるのではないかと書いたことがある。

• PlaceEngineのプライバシー懸念を考える, 2007年5月27日の日記
• ユビキタス社会の歩き方(2) ストーカーから逃れて転居したら無線LANを買い換える, 2007年8月18日の日記
• デイリーポータルZ 記者の家を探しに行く, 2007年10月21日の日記
• 最終回： PlaceEngineの次に来るもの そしてRFIDタグの普及する未来, 2007年11月4日の日記

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

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

• ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する, 2007年11月5日の日記
• 「違法性が怖くてイノベーションができるか」？ 著作権法と電波法の場合, 2007年11月9日の日記

PlaceEngineの場合に、違法性があるかもしれないと感じられたのは、PlaceEngineが観測するのは、他人が通信するために発信している電波信号（家庭の無線LANアクセスポイントが、その家庭内の無線LANクライアントと通信するために発信している信号）を、第三者として傍受したもので、それを他人に利用できる形で提供しているからだった。

それに比べて、Bluetoothの機器探査（device inquiry）はどうか。まず、これは「傍受」にあたらない。当該機器からの応答信号は、こちらから呼びかけたのに対して返ってくるものであるから、常に1対1の通信であり、機器探査をしている者はその通信の当事者である*3*4。

Bluetooth対応携帯電話を、検出可能設定のままオンにして電車に乗っている人が、はたして他人から探知されることを予定しているかといえば、いないだろう。しかし、それを現行法で抑制できるかというときに、電波法59条は（その趣旨からして）筋が違うように思う。

Bluetoothは低消費電力を利点とした通信規格であり、できるだけ電波を出さないようになっているところ、device inquiryを繰り返し受けて、応答の電波を何度も出すというのは、無用な電力消費を強いられている（僅かであろうが）と言うことができるかもしれない。これが迷惑行為とみなされるようになる可能性はあるかもしれない。

商業的に活用される懸念、CGM的に蓄積される懸念

私は、このような行為が何ら規制されないのは、プライバシー保護の観点からまずいと思っている。だからこそこのような実演を今している。

これだけ多くの携帯電話が、Bluetooth機器探査に応じる設定のままで持ち歩かれているとなると、マーケティング目的での活用がまず発想されるところだろう。

店内の客がどの棚の前に長く滞在したかを調べるとか、過去に何回訪れたことのある客かを判別するためなどの目的で、商業施設が人々のBluetoothのMACアドレスを記録し、蓄積し、共有するようになるかもしれない。

それはどこまで許されることなのか。これはまさに、2003年にRFIDタグの未来が一大ブームになったときに、さんざん様々なシナリオを示して、問題点を訴えていた話そのものである。

個人情報保護法が守ってくれるかというとそうでもない。こうしたユニークIDは、携帯電話の契約者固有IDと同様で、住所氏名と紐付けない限り「個人情報」に該当しないというのが、日本の個人情報保護法の解釈の通説らしい。

RFIDタグはまだ広く出回っていないが、Bluetooth対応携帯電話の広がりは、今まさに広がりつつあり、止められそうにない。これを商業的に活用するのはアリなのか、ナシなのか。

私としてはナシということになるべきだと思うが、その根拠はどこに求めればよいのだろうか。「無用な電力消費を強いられることが迷惑」という路線でくい止めることができるだろうか。

商業的な活用はそのような倫理でくい止めることができるかもしれないが、個人が勝手に探査してMACアドレスを公開したり、CGM的に多数の人で情報を寄せ集めて共有する行為はくい止められないかもしれない。

2003年のRFIDの議論で、私は、「自動車ナンバープレートだって、個人が自宅前で撮影して番号読み取りをしたものを、インターネットで共有するような行為が横行するようになるかもしれない。同様にRFIDだって……」ということをどこかに書いた記憶がある。Bluetoothでも同じことが懸念される。

日本は、欧州と違って、Googleのストリートビューの自動車ナンバープレートさえ、自動ぼかし処理なしに開始されている。政府がそれをくい止めないような国である。

英語圏での状況、対策の研究事例

今回、思い出したかのようにBluetoothの件を書いたのは、2月16日に「RFID A GoGo!」というブログの「MACアドレスによるユニークIDトラッキング」というエントリで次のように書いて頂いたのがきっかけだった。

我々の身の回りにユニークIDを持つRFID機器が既に入り込んできている。それもアクティブ型で、平文のIDをビーコン送信するという凶悪な奴だ。なのに、せいぜい数cmの読み取り距離しかないe-パスポートには悲鳴を上げる連中もそのタグの利用については僕の知る限りの欧米のメディアでは全く口を閉ざしている。

…ともったいぶって書いてはみたが、何のことは無いWiFi機器の話だ。（略）なぜプライバシー論者はこの問題について沈黙を保っているんだろう。

幾つか思いつくキーワードを組み合わせてGoogleで検索するというやり方だったので網羅性は保障できないが、英語ではMACアドレスによるユニーク IDトラッキング問題に関する記事はまったく引っかかってこなかった。まさかこれを思いついたのは俺が初めてじゃないよな、と思いながら、ふと日本語で検索してみると高木浩光氏のサイトで取り上げられているのを見つけた(高木浩光＠自宅の日記: 最終回： PlaceEngineの次に来るもの そしてRFIDタグの普及する未来)。さすがの慧眼に感服するほかはない。が、個人的にはRFIDのユニークIDトラッキング問題が話題になった頃の舌鋒の鋭さが無いのが気になった。

MACアドレスによるユニークIDトラッキング, RFID A GoGo!, 2009年2月16日

「英語ではMACアドレスによるユニークIDトラッキング問題に関する記事はまったく引っかかってこなかった」とのことだが、そんなことはない。Bluetoothに関する同様の指摘は以前から出ていて、たとえば、最近でも以下が話題になっている。

• Bluetooth used to track people's movements, Telegraph, 2008年7月22日
• UK researcher finds Bluetooth more of a privacy threat than RFID, Engadget, 2008年5月8日
• Tracking People Using Bluetooth, Slashdot, 2007年11月11日

実験事例の報告はいくつも出ているし、研究論文での指摘や対策方法の提案もある。

• M. Haase and M. Handy, BlueTrack–Imperceptible tracking of bluetooth devices, Ubicomp poster proceedings, 2004.
• F.-L. Wong and F. Stajano, Location privacy in bluetooth, LNCS 3813, pp.176-188, 2005.
• J. S. Wasson, J. R. Sturdevant and D. M. Bullock, Real-Time Travel Time Estimates Using MAC Address Matching, ITE Journal, Vol. 78, No. 6, 2008.
• M. Pels, J. Barhorst, M. Michels, R. Hobo and J. Barendse, Tracking people using Bluetooth, Endreport of a research project about tracking people with Bluetooth, 2005.
• V. Kostakos, The privacy implications of Bluetooth, arXiv:0804.3752, 2008.

根本的には、無断でトラッキングされることがないよう、Bluetoothのプロトコルを改善するべきところと思うが、変えようとしても普及の勢いからして当面はこのままだろう。少なくとも、今後出てくる新しい通信方式においては、同じ轍を踏まないようにしてもらいたいものだ。そのためにも、すべての技術者にこの問題への理解を深めて欲しいと願う。

追記（8日）

続編を3月7日の日記に書いた。

■ ユビキタス社会の歩き方(6) Bluetoothの「デバイスの公開」「検出可能にする」はオフに

上記の通りのリスクがあるので、Bluetoothの「検出可能にする」は、必要なとき以外、オフにしておいたほうがよい。*5

機器によってこの設定の名称が異なるようで困ったことだが、手元にあるソフトバンクモバイルの携帯電話では、「Bluetooth」の「マイデバイス設定」のところにある「デバイスの公開」という設定を「Off」にする。

図5: ソフトバンクモバイルの携帯電話での設定画面

Bluetoothの「On/Off設定」のことは知っていても、この「デバイスの公開」のことを知らない人が多いのではないだろうか。ここはデフォルトで「On」になっている。

Bluetoothヘッドホンで音楽を聴くなど、ときどきBluetoothを使う際に、煩わしくないよう、常時Bluetoothをオンにしておくということがあるかもしれないが、そういう目的でなら、「デバイスの公開」までオンにしておく必要はない。

「デバイスの公開」は、新しい接続機器とペアリングする際にだけ、一時的にオンにすれば十分なのだが、そのことがあまり知られていないのではないだろうか。

注記：この日記は、3月1日に書き始めたものの翌朝までに完成しなかったため、3月3日の朝に掲載した。

■ 首都高速都心環状線でBluetooth追跡できるか + 続・山手線

渋滞気味の首都高速

前回の日記に引き続き、今回は首都高速都心環状線を3周してきた。できるだけ車が多い方がよいので、渋滞していそうな夕方に行ってきた。今回は内回り。1周はほぼ25分だった。大半の場所で時速30キロほどの軽い渋滞状態で、江戸橋JCTから竹橋JCTまでは止まりつつ進む渋滞状態だった。左側の車線を走行している。

結果は図1のとおり。

図1: 首都高速都心環状線でのBluetooth探査の結果

予想以上に見つかる数が少なかった。10メートル以内というBluetoothの通信可能距離では、前の前の車くらいの距離でもう通信できないようだ。隣りの車線に該当する車が来てもすぐに離れてしまう*1。

電車や駅という環境のほうが特殊なようだ。

ラッシュアワーの山手線

前回の日記の実験も、山手線にしては人が少ないタイミングだった。日曜の夜だったので、渋谷から新宿あたりは混雑していたものの、東京駅周辺では空席が出るほど空いていた。

そこで、本来の山手線でいかほどの事態となるのかを確かめるべく、金曜日の朝に3周してみた。

池袋7:01着、池袋10:11着予定の列車に乗り、同じ車両（6両目）のほぼ同じ席（ひとつ左の席）に座った。3時間10分で1190個のIDが観測された。

2周目の混雑で徐々に運行に遅れが生じ、2周目の新宿で、2分遅れで着、「運転間隔調整」とのアナウンスで2分30秒の停車。3周目の巣鴨でも「運転間隔調整」。3周目の日暮里で、3分遅れで着、「運転間隔調整」で2分停車。3周目の大崎で4分遅れ、その後回復して、1分遅れで最後の池袋に着いた。日暮里から浜松町あたりまでが特に混雑するようで、8時台の周回では、田端で混雑、日暮里で大混雑、上野から神田までで超激混雑（人が押し合って停車時に倒れそうになる状況）、東京から浜松町までが激混雑、浜松町からは普通の混雑という感じだった。

図2: 平日朝における山手線の乗降パターン

今回はJavaアプレットを改良して、駅の位置を秒単位で合わせるようにした。駅の着時刻（ドアがが開いた時刻）と発時刻（ドアが閉まった時刻）を秒単位（5秒の精度）でメモした記録に基づく。駅の印の長さ（半円中心間の長さ）が停車時間を表す*2。単発IDが沢山観測される「山」が、駅の前後に2つずつ現れることがわかる。これは、ホームにいる人々のIDが、ホームに入っていくときとホームから出て行くときに集中して観測されるためと思われる。

また、とびとびに観測された同じIDを点線でつないで表示するようにしたので、乗降パターンを読み取りやすくなった。前回のデータも新しいアプレットで以下に再掲する。（駅の時刻は分単位でおおよそ。）

前回のように、約30分間隔で単発が2度現れる事例があるか調べてみたところ、1つあった。

00175CXXXXXX 2009-03-06.08:09:25 34:09 | 192,289

時刻を調べると、巣鴨を出て駒込に着く前と、品川を出て大崎に着く前で、どちらも駅から離れた位置だ。やはり、対向列車の中の人をすれ違いざまに捉えたもののようだ。駒込から品川に向かった人なんだろうか。あるいは、日暮里あたりから新橋あたりに行く人が、外回り列車の混雑を嫌って、遠回りして内回りを使ったのだろうか。

さて、この2回の観測（3月1日日曜日の夜と、3月6日金曜日の朝）で、両方に居合わせたBluetooth端末はあるだろうか。データを突き合わせてみたところ、駅の設備らしきもの（約1時間毎に現れる）を除き、また、両方で単発で現れたものも除いて、それでも4つも見つかった。

001C43XXXXXX 2009-03-01.20:31:30  0:00 | 395
001C43XXXXXX 2009-03-06.07:06:04  3:52 | 12,13,14,15,16,17,19,20,22,23

1日の夜に鴬谷付近で一瞬現れた人が、6日の朝に巣鴨から田端に移動している。

00175CXXXXXX 2009-03-01.21:44:48  0:00 | 603
00175CXXXXXX 2009-03-06.08:12:36 20:02 | 201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258

1日の夜に新橋付近で一瞬現れた人が、6日の朝に田端から新橋に移動している。

001CEEXXXXXX 2009-03-01.19:18:07 10:35 | 187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217
001CEEXXXXXX 2009-03-06.09:13:30  0:00 | 374

1日の夜に巣鴨から上野に移動していた人が、6日の朝に巣鴨でドアが開く10秒前*3に一瞬現れた。

00175CXXXXXX 2009-03-01.19:36:49  0:00 | 240
00175CXXXXXX 2009-03-06.09:31:27 10:34 | 425,426,431,437,448,449,450,451,452,453,

1日の夜に東京駅付近で一瞬現れた人が、6日の朝に秋葉原から浜松町に移動している。

これはちょっと信じ難い。状況からして一般の人のように思えるが、こんなにも小さくない確率で同じ人に居合わせるものなのだろうか。

■ Windows Mobileの「オーナー情報」設定に注意

• RFID付き米国旅券の情報を遠隔地から収集する試み, スラッシュドット, 2009年2月7日

  米国籍パスポート(所有者)が接近すると爆発する爆弾（略）

とあるように、無線で近くの人のIDが読めてしまうことの危険性は、米国ではテロの現実性もあって、かねてより話題になっている。

ところで、一昨年、はじめてWindows Mobile機を買った際に気になったものの、小ネタだったので放置していた件があるのだが、やっぱり書いておく。

Windows Mobile搭載機器（スマートフォンなど）を買ったとき、最初にやることといえば、いろいろな設定を試してみることだろう。最初に目につくのは「オーナー情報」（図1）の設定。ここに名前と連絡先を書いておくと、電源を入れたときに表示されるようにできる。

図1: Windows Mobileの「オーナー情報」設定

万が一どこかに置き忘れてしまったときに連絡を頂けるのを期待して、名前と連絡先、メッセージを書き込んだ。こうしておくと、電源を入れたときに図2の写真（右）ようになる。

図2: 「マイ インフォ」に連絡先とメッセージを表示

実際、私も最初はそうしていた。ところが、何日かして、Bluetoothを使おうとしたときのこと、PC側で、図3の画面（右）が表示された。

図3: Bluetoothを検出可能に設定したときの様子

「どこで氏名なんか設定したっけ？」とあちこち探してみたところ、なんと、「オーナー情報」の「名前」欄に設定した文字列が、Bluetoothの表示名として検出されてしまうのだった。

このまま電車に乗って「『高木浩光』が来ましたよー」と周囲に知らせてしまうところだった。危ない危ない。

ところが、Windows Mobileのあちこちの設定項目を探しても、Bluetoothの表示名だけ変更する方法が存在しないようだった。しかたがないので、「オーナー情報」の「名前」欄に機種名を記入して、名前は住所のところに書くようにした（図4）。

図4: 対策後の様子

まあ、これで解決だけれども、「マイ インフォ」のところの冒頭に機種名が出てしまうのがマヌケだ。Microsoftとしては、どうしろというつもりなのだろうか。

PC用のWindowsの場合にどうだったかというと、よく知らないのだが、Windows XPのころからだっただろうか、「YOUR-XXXXXXXX」というランダムな名前がデフォルトとなっていて、あまり問題を感じた記憶がない。

もっとも、コンピュータ名を設定しておくとネットワークに表示名として放送されるというのは、昔からある話で、たとえば、1990年代からMac OSでは、AppleTalkに「○○のコンピュータ」という名前を流していたのだから、Macユーザにとっては自然なことかもしれない。

しかし、図1のように、住所や電話番号という、非公開を予感させる項目と並ぶ形で、入力するようになっている「名前」欄が、まさか公開状態になるとは、ちょっと予想できなかった。

ちなみに、Mac OS Xでは、「システム環境設定」の「共有」設定の「コンピュータ名」に設定した文字列が、ネットワークに放送されるようになっているので、そういう誤解は生じないと思われる。

図5: Mac OS Xの「共有」設定

ただ、デフォルトでここに所有者の氏名が入るようになっている。これが、ファイル共有を使うときや、LANに接続したときだけに放送されるのなら、まだよいのだが、この名前は、Bluetoothで「検出可能にする」設定にしているときにも通知されてしまう。

そのことはちゃんと理解されているだろうか。イベント会場など、Macユーザのいそうな場所でBluetooth機器を使おうとしたときに、「○○○○の MacBook」といった名前が出てくることがよくある（図6）。わかっていてそうしているのならよいのだが。

図6: WASフォーラム・コンファレンス2008の会場でBluetooth機器を探査した際の様子

■ 検出可能Bluetooth端末の3/4がシャープ社製か

1日の日記を書いた時点では、検出されるBluetooth対応携帯電話が多いのは、それだけBluetoothを使っている人が増えていて、「検出可能」設定のことを知らないためではないかと思っていたのだが、ブックマークコメントやその他の反応を見ると、そうではなく、Bluetoothが有効になっていることに気付いていない、さらにはBluetooth機能が搭載されていることさえ知らずにいる人が多いのではないかとのことだった。そう考えられる理由として、検出されるものが、シャープ社製のソフトバンクモバイル用端末に極端に偏っているようだからとのことだった。

そこで、1日の実験と6日の実験で検出された合計（ユニーク数）2332個*1のMACアドレスについて、上位24ビットの製造者固有ID（OUI）から登録製造者名を調べてみた（表1）。

これを、社名表記の揺れを吸収して会社名別に集計すると、表2のようになる。

たしかに、シャープ社製が極端に多く、全体の4分の3を占めている。続いてパナソニック社製が1割弱となっている。

もっとも、これはBluetoothデバイスの製造者を指しているので、携帯電話端末の製造者を指しているとは限らない。たとえば、私が使っているイーモバイルの「S11HT」は、HTC社製であるが、BluetoothのOUIはTexas InstrumentsのIDとなっている。

私の実験では、デバイス探査の後の名前問い合わせ処理をしていないので、MACアドレスしか記録していないが、トラックバックを頂いた方のブログによると、名前問い合わせの結果を記録したところ、ソフトバンクモバイル用のシャープ社製端末らしき名前が多くを占めるとのこと。

• Bluetooth の実験, eggshell blue, 2009年3月8日
• Bluetooth Scanning でソフトバンク携帯の検出率が妙に高かった理由, eggshell blue, 2009年3月8日

所有者も気付かないようなBluetooth機能なのに、なぜ、デフォルト設定で有効かつ検出可能としているのかについて、「ちかチャット」という機能を使ってもらいたいためではないかと考察されている。

「ちかチャット」について調べてみたところ、2007年10月に書かれたR25の記事が見つかった。

• 地下でもやりとりできる “ちかチャット”って知ってる？, R25, 2007年10月19日

  「たしかにあまり宣伝などしていないので、知らないユーザーさんも多いかもしれません。でも実は、ボーダフォンのころ、2006年の４月から導入されています。機能には、10ｍ以内にある対応機種を探してチャットに誘う『おしゃべりモード』と、質問を投げかける『おしえてモード』があり、いろいろなコミュニケーションが楽しめると思いますよ」（ソフトバンクモバイル広報（略））

  （略）

  「ひとりでライブイベントに行ったときに使ってます。『誰か話そうよ。今の曲よかったよね！』なんて言ってチャットに誘うと、『うん、最高！』なんて返ってくる。知らない人とも仲良くなれたりして面白いよ」（26歳・会社員）

本当にそんなふうに使われいてるのだろうか……。

追記（5月18日）

5月18日の日記にその後わかったことを書いた。

■ 東京地下鉄でBluetooth探査

時計に表示

1日の日記を書いて以来、時計を見ると山手線に見えるようになってきた。いっそ時計上に表示してはどうかと、デバイス探査しながらリアルタイム表示するようにしてみた。

図1: 山手線内回り:秋葉原→池袋

これなら、色を変えればどこでも環状線気分だ。

図2: デバイス探査しながら時計上にリアルタイム表示（丸ノ内線）

東京メトロで乗り鉄

昨日は、出かけたついでに寄り道して、東京メトロ各線に乗ってみた。

図3: 丸ノ内線:池袋→新宿
日比谷線:恵比寿→北千住
千代田線:北千住→表参道
半蔵門線:表参道→押上
銀座線:浅草→渋谷
副都心線:渋谷→小竹向原

6路線約4時間で329個のBluetoothデバイスが検出された*1。あまり人は多くなかった。公開設定にしている人の割合は、これまでの経験から、だいたい10人〜15人に1人くらいと感じる。

既知との遭遇

さて、同じ人に遭遇しているだろうか。6路線のログを集計してみると、さすがに同じ人はいなかった。では、この6路線のログを1日夜の山手線4周と7日朝の山手線3周と突き合わせるとどうか。

なんと、驚いたことに4人もいた。

001CEEXXXXXX 2009-03-14.18:04:06 16:56 | 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
001CEEXXXXXX 2009-03-01.21:15:13  3:52 | 519,525,530

この事例は、14日土曜日に丸ノ内線で池袋から東京まで乗り合わせた人が、1日日曜日の山手線でも、高田馬場から池袋まで乗り合わせていたことを示している。図4の青い線がそれである。

図4: MACアドレス「001CEEXXXXXX」の検出記録

00175CXXXXXX 2009-03-14.18:09:45  0:21 | 16,17
00175CXXXXXX 2009-03-01.21:20:09  0:00 | 533

この事例は、14日に丸ノ内線の茗荷谷駅で遭遇した人が、1日の山手線でも池袋駅で遭遇していたことを示している。

002265XXXXXX 2009-03-14.20:46:28  0:21 | 78,79
002265XXXXXX 2009-03-01.21:40:34  0:42 | 591,592,593

この事例は、14日に日比谷線の秋葉原駅で遭遇した人が、1日の山手線でも東京駅で遭遇していたことを示している。

00175CXXXXXX 2009-03-14.21:49:49  0:00 | 0
00175CXXXXXX 2009-03-06.07:37:22  0:00 | 101

この事例は、14日に半蔵門線の表参道駅で遭遇した人が、6日朝の山手線でも品川駅で遭遇していたことを示している。

他にも、2月の予備実験中の際のデータとも突き合わせてみたところ、1人見つかった。以下は、3月14日に日比谷線で六本木から上野まで乗り合わせた人が、2月19日の24時すぎに山手線の上野駅で遭遇していたことを示している。

00175CXXXXXX 2009-03-14.20:24:35 25:25 | 16,17,18,19,20,22,23,24,25,31,32,33,34,35,36,37,38,39,40,41,42,44,45,47,51,63,64,65,66,67,68,69,70,71,72,74,75,76,88
00175CXXXXXX 2009-02-19.00:08:21  0:00 | 7

これほどまでのものとは……。329人中5人もの人が過去に記録されていた。

知人の周囲で実験しない

ところで、先日の日記のリンク元を辿ったところ、mixi日記から参照されており、次の研究事例がある*2ことを知った。

• Bluetoothデバイスの検出履歴を用いた日常行動の分節化, 河野研究室 研究テーマ・トピック
  http://mixi.jp/view_diary.pl?id=1107559681&owner_id=17436 より

そのmixi日記の翌日のエントリを見たところ、この方曰く、学会やその懇親会、同窓会の席で、Bluetooth探査のログをとっているのだという。これはゾッとしない。そんなことをしたら、知人のMACアドレスを知ることになってしまう。

私は、研究会や講演会、宴会等、知人のデバイスだとわかってしまうような場では、ログに残るようなデバイス探査は行わない。これはお約束しておきたい。*3

知人のIDを調べるのは、イベント会場の無線LANでパケット傍受するくらいに不適切な行為だと私は感じる。（同様に、無線LANパケットを傍受して知人のWi-FiのMACアドレスを知る行為も慎みたい。Bluetoothはオフにできるが、無線LANはそのような場で使わざるを得ない。）

そう言ったところで、誰でも簡単にこのようなBluetooth探査ができてしまうのだから、逆に、周囲でデバイス探査されていることを検知するプログラムを作って*4、警報が鳴るよう走らせておきたいところだ。

もしかすると、既に街のあちこちでBluetooth探査の電波が出ているのかもしれない。