とりあえず中古で所有者が変わる上に、ユーザーが任意に変更/クリアできない変数を使うセンスがアレという感じ。 仕様を見た感じでも送信されないってパターンの記載が無いし、感じ的にWindows Media Playerとかの「一意のプレーヤー ID をコンテンツのプロバイダに送信する」が強制ON状態で固定。 WMPは所詮アプリとしてしか固有IDを持ってないからOS再インストールでもすれば変わるという期待が取れる。（GUIDだし)
脆弱性という観点で見るとIMEIの取得には本来「端末のステータスと ID の読み取り」という権限が必要だけど、持たないアプリやWebブラウザがこの
そりゃひろみちゅ氏も怒るわ (スコア:1)
この記事 [takagi-hiromitsu.jp]で
と危惧していた事が現実に起きたわけですしね。
＃そういえば端末固有IDを簡単ログインに使っていたせいで個人情報漏洩事故が発生したの、ちょうど１年前じゃなかったっけ。
Re: (スコア:0)
User-agent や HTTP の勝手ヘッダに IMEI を入れるのは問題ではあるけど、それが「脆弱性を作りこんで」いるかというと、かなり微妙。
とりあえず、みんなで偽IMEI付きUser-agent や偽IMEI入り勝手ヘッダを生成してアクセスしまくってやれば、そんな仕様には意味がなくなって変えざるを得なくなるのではないですかね。
Re: (スコア:3, 参考になる)
とりあえず中古で所有者が変わる上に、ユーザーが任意に変更/クリアできない変数を使うセンスがアレという感じ。
仕様を見た感じでも送信されないってパターンの記載が無いし、感じ的にWindows Media Playerとかの「一意のプレーヤー ID をコンテンツのプロバイダに送信する」が強制ON状態で固定。
WMPは所詮アプリとしてしか固有IDを持ってないからOS再インストールでもすれば変わるという期待が取れる。（GUIDだし)
脆弱性という観点で見るとIMEIの取得には本来「端末のステータスと ID の読み取り」という権限が必要だけど、持たないアプリやWebブラウザがこの
Re: (スコア:0)
仮に、ドコモのプレーヤーがIMEIではなく、端末ごとに特有のドコモプレーヤーIDを持っていてそれを送っていたとします。それで問題は解消するでしょうか？ROM領域に入っているアプリが端末を特定できるIDを送信すれば、名寄せが可能になります。名寄せが可能になることを問題にするなら、取得できたIDで端末が特定できることが本質であって、そのIDがIMEIかどうかは問題に関係ありません。アクセス制御を迂回してIMEIを取得できたことが名寄せ問題を生んでいるのではないのです。
IMEIが取得できることで名寄せ以外の脅威が発生するというなら、IMEIを取得できたことを脆弱性と言う主張も理解できますが、それは何でしょうか。
Re:そりゃひろみちゅ氏も怒るわ (スコア:1)
仰るとおり解決しないでしょう。端末固有の固定値である限り。
諸悪の根源は親コメントの一行目に有る「ユーザーが任意に変更/クリアできない変数を使う」事なのですから。
個人的には下記を満足して欲しいです。
通知する範囲的には
・通信相手毎に異なる事(例えばホスト名ですが、レンタルサーバー等を考えれば粒度が荒すぎるのでURL全体等)
→これで、名寄せに関する問題は有る程度解決できるでしょう。
・基本は通知しない事
→必要であれば要求を画面に出すといった対応も出来たはずです。新規案件なのですし。
・通知するとしても、ホワイトリスト的運用が容易に出来る事
→設定で例え通知有無が可能となっても、ON/OFFのみでは結局常時ONになりかねないです。「設定変えるのが面倒だし」とかで。
時間軸的な観点から
・ユーザーが望みクリアした場合、必ず前回の値が推定出来ない事
→これが出来なければ意味がありません。推定出来なくさせれば良いのですから「通知しない」も含みます。
・可能で有るならば、一定時間(例えばアプリ起動毎・OS起動毎・最長1時間等）で変化する事
→長期間追跡する必要が無いのであれば、これで十分でしょう。
今回のようなメディアプレイヤー自体が有る程度の期間内、同一コンテンツに決まった値を送るというのも「アリ」だと思います。
送ることによってコンテンツ再生中に回線が途中で切断したり、用事(電話等)で再生中断したり、アプリが死んだ際でも、次回中断箇所から再生を続行が可能になりますから。
# 普通はアプリ側が再生済み箇所を覚えていて途中から要求するべきでしょうから、この程度の事でやり取りすべきではないと思うけど。
ユーザー利便性から
・該当アプリ(と、場合によってはセットとなる提供者)の世界で閉じて、外部に影響を与えない事
→これで、最低限アプリのデータ削除で通信先のサーバーには残るが、他のアプリやデータ(メールとか)をそのまま使い続けたり、後日別情報が無ければ名寄せされず該当サービスの利用再開や譲渡が出来る。
・可能であるならユーザーIDといった真にユーザーと結びつく物で識別し、端末に依存しない事
→例えば修理してIMEIが変わったり、アプリが保持していた値が消えたとしても同じサービスを継続して使い続けられる様に。
例え現時点では名寄せ以外の脅威が無かったとしても、OSが持つセキュリティモデルを崩壊させているという点で脆弱性かと。
「何故？」OSがアクセス権を要求する事で取得を制限していたのか。
アプリ開発時に電話機自体や電話機の状態といった物のデータの属性が「個人に関する情報」であるという意識が抜けていた、若しくはアプリ開発側から「個人に関する情報」で有るからこんな仕様は認められないと拒否しなかったor出来なかったのも問題かもしれません。
# 当然最初にこんなプロトコル仕様を考えた方がより救いようが無いと思いますが。
個人的に「個人に関する情報」を杜撰に扱うのは、外部からの入力を信じてそのまま使ってXSSやSQLインジェクションを起こすWebアプリやバッファオーバーランを起こすアプリ並にイケてないと考えます。
どれも「データの中身」のリスクを正しく評価せず、過小評価して使ってるという点で。
Re: (スコア:0)
例え現時点では名寄せ以外の脅威が無かったとしても、OSが持つセキュリティモデルを崩壊させているという点で脆弱性かと。
まあ言葉の問題ではあるんだけど、それから発生する脅威がないのなら、不具合かもしれませんが脆弱性ではないです。名寄せの問題は、アプリが自分で生成したユニークなIDを送るのはOSでは止められないので、もともとOSが持つセキュリティモデルで防ぐ問題ではありません。
取得されるとOSレベルでセキュリティ上の問題が発生するようなやばい情報なら、その公開を許可するようなオプションを作ること自体が批判されるべきだとは思わないのですか。