「placeengine」を含む日記 RSS

はてなキーワード: placeengineとは

2012-02-04

プライバシを守るためのリンク集 save your privacy

ターゲッティング広告から身を守る

使用するブラウザIE,Firefox,androidブラウザ,...)毎に設定を行う必要があると思います

位置登録データベースから身を守る

これらがなぜ悪なのか:http://takagi-hiromitsu.jp/diary/20111126.html

その他参考リンク

みなさまから情報提供をお待ちしています

リスト漏れているサイト等の情報をよろしくお願いします。

2011-11-18

アフィブログは今回の件で儲かった金額を産総研寄付せよ

===高木先生いいように煽られるターン

セキュリティ専門家PSNに対して怒っているのはネカマがバレたから?

http://blog.esuteru.com/archives/5310454.html

投稿日時:2011年11月9日21:00

Vita終了のお知らせ】 情報セキュリティ専門家PSVitaPlaceEngineを載せたら、集団訴訟ターゲットになる」

http://jin115.com/archives/51825887.html

2011年11月16日 15:20

ゲハ脳の恐怖】 セキュリティ専門家高木先生ブチギレ 「ふざけるな糞野郎。どこのライターか名乗れよ」

http://jin115.com/archives/51826098.html

2011年11月17日 09:58

===高木先生大勝利のターン

SCEPSN利用規約を改訂 & トロフィー情報等の公開の可否をユーザーに選択させる仕組みを検討

http://jin115.com/archives/51826170.html

2011年11月17日 17:24

トロフィー情報問題でPSN利用規約が改訂!ゲームプレイに関係した情報の開示可否も検討

http://blog.esuteru.com/archives/5366930.html

投稿日時:2011年11月17日17:28

-------------------

リアル雑談高木先生の話題を振って「ああ、ネカマのww」という反応を示す輩がいたら、そういう輩とは距離を置いた方が幸せになれる。

間違ってもそういう輩を相手にゲハ脳とか絶対言わないこと。逆ギレされたり色々面倒だから

2011-11-16

Google Location ServerからWi-Fi情報削除とかのまとめ

Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります

ブコメには「Google勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。

(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)

Googleだけの問題ではない

そもそもの問題は、Wi-Fi仕様において、Wi-Fi機器MACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。

まり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか?」との反駁には「はいPlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。

まり、この問題は「GoogleDBから削除してもらう」だけでは全く解決しない。

(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleAppleMSなどを相手取って世界中訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)

考え得る対応

ひろみちゅ先生のご意見(2007年版)より。

(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応

技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。

PlaceEngineを利用していない人(PlaceEngine存在さえ知らない人を含む)に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。

新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。


(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応

技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人(PlaceEngine存在さえ知らない人を含む)に対して周知しなくては問題は解決したといえない。

このようなルールが万人に受け入れられるものかどうか不明。


(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応

暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。

しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。


(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応

法的には最も安全対応技術的にも、MACアドレスリストを提出してもらうことで対応可能。

実質的には公衆無線LANだけしか登録できなくなり、登録数はごくわずかとなってしまう。

まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleオプトインしなければ安心」という誤解を与えかねないという懸念もある。

(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。

今回Googleが提案した方法は、(a)の改良型(あるいは(a)~(c)のハイブリッド)というべきものである。再掲。

Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります

オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPマッピングしないでくれ」という明確な意思表示となるからだ。

SSIDステルス暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法マッピング拒否の意思表示をしていたぞ!」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことからデファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。

これで解決?

解決しない。

ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダマナー」程度にしかなりようがないからだ。オプトインですら、であるrobots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Google責任ではないし、Googleに責を負わせても全く意味がない。

最初に述べた通り、そもそもの問題は「Wi-Fi機器MACアドレスをタレ流しにしている」ことであり、これはWi-Fi仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。

また、Wi-FiMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙もっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである

一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはApplePlaceEngineが今までしてこなかったことだ。

おまけ

ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策実施済のようである。これにより、もしMACアドレスSSID漏れたとしても、その所在地こんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。

もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。

追記

PlaceEngineより、Google提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。

PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて

GoogleからGoogle Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法SSIDに"_nomap"文字列を追記する方法)が公開されました。

PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。

また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。(「位置推定の改善」をご参照ください)

これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。

そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中合意ルールを形成してゆく必要がある。先は長い。

2010-03-05

セカイカメラがAppStoreから消滅な件の雑感

ttp://fladdict.net/blog/2010/03/sekaikamera.html

■1: SDK違反

ぱっと見PlaceEngineは、普通にiPhone SDKでは実装できない。なので、プライベートAPIやローレベルの何かをゴニャゴニャして、Appleの怒りに触れた可能性が1つ。

この場合、iPad6月に予想されるiPhone OS4のリリースにより、アプリが動かなくなることが原因とが考えられる。 iPadの最終試作機で既存アプリテストしてたら、セカイカメラが動かないのが発覚して・・・ みたいなシナリオか。 このケースでは、Appleが公式APIサポートしない限り、wifiハック系は全滅ということになる。

もし原因がこのケースだった場合、削除ウンヌンより、SDK回避して作ったものをミドルウェアとして販売して大丈夫なんか?ってことのほうが重要になりそう。


■2: プライバシーセキュリティポリシー的な問題

PlaceEngineは、ご存知のとおり現在位置の情報wifiから独自に取得する。 ここがAppleプライバシーセキュリティポリシーに触れた可能性。 iPhoneGPS系は使用時に現在位置の取得を明示的に表示しているが、wifi位置情報引っこ抜くことが、ここに抵触をしているケース。ついでに、この情報サーバーに投げちゃっているところも問題かもしれない。

この場合は、位置情報を取得していることを明示的に表示すれば復活する可能性大。


■3: アップルの潜在的競合とみなされた

将来、Appleがこの分野に手をだす為に、とりあえず潰されたケース。

AppleがAdMob Quattro Wirelessを買収した件や、サードパーティ位置情報広告を禁止した件、にからむ流れのケース。

Apple位置情報広告に手を出す場合、 位置情報の正確な取得には地域間のwifi情報データベース化する必要がある。で、その情報アップルが独占したいと考えた場合は、競合の意図的な排除は十分にありえる (というか、それこそがプラットフォーマーの特権)。 wifiで位置計測をする技術は、デバイスホルダーが持つのが最強だもの。自分アップルなら他人にそんな情報はあげたくないところ。 

この場合は、1番か2番を対外的な理由として発表しするだろうから、直接の観測はむずかしいところ。

http://anond.hatelabo.jp/20100305130857

PlaceEngineって無料なんだね。しらなかった。

あと、PlaceEngineSony関連企業だと言うことも今知った。

そら、排除されるかもね。

iPhoneの特定アプリ削除は契約の問題なんじゃないかなー

(追記)

http://anond.hatelabo.jp/20100305133108 にて単純に周囲のWi-Fiを探索し、一覧表示するアプリが削除された( http://www.efusion.co.jp/en/about/ewifi_pulled.html )という指摘があったので、以下の文章は戯言でした。情報ありがとう。

iPhoneでのセカイカメラなどの公開停止について。はじめに、あまり根拠のない憶測であることを書いておく。

今回標的にされているのはPlaceEngineで、公式サイトで( http://www.placeengine.com/ )もPlaceEngineを使用しているiPhoneアプリが公開停止になっていることを通知している。ここ( http://jp.techcrunch.com/archives/20100304tonchidot-sekai/ )では、「Wi-Fiの利用の問題があった」という表現になっているんだけど、それは違うじゃないだろうか。

PlaceEngineの仕組みを簡単に説明すると、周りにある複数のWi-Fi機器MACアドレスSSID電界強度とPlaceEngineがもっているDBを照らし合わせ、そこから位置を推測するというもので、この周りにあるWi-Fi機器リストを作成するためのAPIが非公開(?)でそれが問題になっているという意見を散見したのだけど、単純に周囲のWi-Fiを探索し、一覧表示するアプリが削除されたという情報はなかった。

ここでちょっと後戻りするんだけど、iPhoneOSネイティブ位置情報取得機能のひとつとして、Wi-Fiが使用されていることを書いた( http://anond.hatelabo.jp/20090929150634 )。このWi-Fiによる位置情報取得にはSkyhook社というPlaceEngineの競合他社の技術が使われている。んで、契約関係でゴタゴタしているんじゃないだろうか。

 
ログイン ユーザー登録
ようこそ ゲスト さん