2008年10月01日
DoCoMoのGPSでの簡易詐称チェック
ケータイ位置情報を利用したエンターテイメントサイト(特に商品等金品が絡むもの)を作る場合、一番のキモになるユーザによる位置情報詐称の予防だが、大抵のケータイ位置情報は、詐称に関する脅威が通信経路でのユーザによるクエリストリング等書き換えなので、比較的簡単な方法で阻止できる。
うちでも以前1つの方法を紹介したし、他にも別解を思いついたり教えてもらったり、私が知ってるだけでも後2、3はある。
ただ、DoCoMoのGPSだけは、今までいかんともし難かった。
DoCoMoのGPSの場合、端末側の機能として、GPS測位した位置情報の他に、過去の履歴とかアドレス帳からの位置情報とかを選択でき、かつその差がを受け側では全く見分けがつかないので、エンタメサイト企画泣かせだった。
どうすんべと思って、端末の履歴の残せる分だけユーザの送ってきた位置情報を溜めておいて、過去の位置情報と全く同じのが送られてきたらアウトにするか、これならGPS測位ならまず毎回座標値は変わるので判定できるかも、とか思ったりもしたんだけど、
これだと確かにGPS測位の履歴からの詐称は防げるけど、アドレス帳とかからの詐称は防げないし、またGPSの測位が失敗すれば自動的に基地局位置情報にフォールバックされるけど、基地局位置情報レベルじゃ過去の座標値と一致することもあるだろうし、ということで明快な解決策がなかった。
ところが、先日、ほとんど私と唯もう一人、ケータイ電話の位置情報詐称にこだわっているGOGAの石丸さんのブログを見ると、すごいアイデアが。
GPSで位置を取った後、確認のためにオープンiエリアの基地局経緯度も続けて確認し、その誤差が一定範囲内の場合のみ、そのGPS位置の取得を認める、というものだった。
これは慧眼。
オープンiエリアの仕様は、全キャリアの位置情報取得方の中で唯一、リダイレクトで位置が取れる仕様だ。
だから、こんな感じの処理をすれば、ユーザがページ上の位置情報リンクを押す回数は1回だけで、GPSとオープンiエリアの両方の位置が取れる。
#!/usr/bin/perl
use strict;
use warnings;
my $q = CGI->new;
unless ( $q->param('lat') || $q->param('LAT') ) {
print <<EOF
Content-type: text/html
print "<a href="http://hogehoge.jp/gps2openiarea" lcs>GPS</a>
EOF
} elsif ( $q->param('lat') && !$q->param('LAT') ) {
print "Location: http://w1m.docomo.ne.jp/cp/iarea?ecode=OPENAREACODE&" .
"msn=OPENAREAKEY&nl=http://hogehoge.jp/gps2openiarea&posinfo=2&arg1=lat%3d" .
$q->param('lat') . "&arg2=lon%3d" . $q->param('lon') . "\n\n";
} else {
print "Content-type: text/html\n\n";
print "GPS LAT: " . $q->param('lat') . "<br />";
print "GPS LON: " . $q->param('lon') . "<br />";
print "ANT LAT: " . $q->param('LAT') . "<br />";
print "ANT LON: " . $q->param('LON') . "<br />";
}
ワンアクションといっても、ユーザへの「位置情報を教えてよいか?」アラートはGPSとiエリアの2つ分出るのだけれど、しかしこれも逆説的ながら、それでなくてもDoCoMoのGPSは「データソースをリアルタイム測位にしますか?履歴にしますか?アドレス帳からにしますか?」とか色々聞いてきて、元からアクション数が多いので、いまさらiエリア分が増えたところで何ほどかと?違うか。
問題はあるとすれば、リダイレクトなのでオープンiエリアの「http://w1m.docomo.ne.jp/cp/iarea」への遷移がGETになり、位置情報の通知先や引き継いでいるパラメータが露見してしまうこと。
ここで露見したURLにPOSTで嘘のURLを投げられてしまえば、チェックの基準となるオープンiエリアごと、詐称されてしまう。
これについては、検査対象となるGPSの位置情報をパラメータで引き継がず、セッションで引き回してやって、かつそのセッションを
- かなり短い有効期間を設けてやり、それを過ぎると無効にする(リダイレクトでの遷移が想定されているので、有効期間は短くて問題ないはず)。
- オープンiエリアのランディングページだけでなく、サイト内のどのページにアクセスがあっても、セッションは無効にする。
といった対策をしてやれば、十分じゃないかと思う。
ただ、基地局位置情報をベースとして、そこから有効範囲内の位置情報がGPS値として返されたかどうかで有効/無効判定するので、現在地近くの店舗情報などの位置情報を送付されると詐称検出しようがないんだが、それはもう防ぎようがないので、許容するしかないんじゃないかな。
また、GPS位置情報をiエリア位置情報で認証するなら、元からiエリア位置情報をベースにすればええやん、という話もあるわけですが。
でも例えば、「渋谷のハチ公前にくればイベント発生」みたいなシナリオにする際に、iエリア位置情報を使ってるからハチ公から半径5km以内は誤差としてOKとする、じゃああまり面白くないですよね。
やっぱりGPSを使って、かなり精密なクリア判定をしてやりたいわけですけど、でもGPS単体じゃ詐称され放題になっちゃうので、補助的にiエリアを使って詐称の敷居を高くしてやるという、そういう話ですね。
1エントリ・1アイヌリンク
2008年10月12日(日)~13日(祝)、渋谷O-nestというところで。
最近ずっとアイヌリンク採り上げてたら、会社の同僚が教えてくれました。
アイヌのムックリ奏者も多数参加とのこと。
トラバ頂きありがとうござます。慧眼とは恐縮です。このアイデアはdoodleヘビーユーザのMARさんという方に頂いたもので、今作っている別のシステムに実装予定です。docomoもいろいろな仕様で困りものですが、iPhoneよりは頑なではないので、位置情報が外に出せるだけでもありがたいと最近では思っていたりします。。。
![[ここギコ!]](http://kokogiko.net/logo.png)





・MovableType 3.2、MT::App::Trackback.pmの修正(selvirremdor)
・MovableType 3.2、MT::App::Trackback.pmの修正(antulaseesi)
・3D PaPaGO! 登場(pereezdkv)
・MovableType 3.2、MT::App::Trackback.pmの修正(spezinstr)
・MovableType 3.2、MT::App::Trackback.pmの修正(dimdimov)
・MovableType 3.2、MT::App::Trackback.pmの修正(deanteywee)
・MovableType 3.2、MT::App::Trackback.pmの修正(keyjiolso)
・MovableType 3.2、MT::App::Trackback.pmの修正(leyliautumfe)
・MovableType 3.2、MT::App::Trackback.pmの修正(selvirremdor)