NHN JapanのLINEアプリが大人気だ。
全世界のユーザー数が4000万人を超え、国内でも1800万人のユーザーを突破したという。 今でも月に500万人が登録し続けており、年内にも1億ユーザーを目指す、という。
驚くべきはその成長率であり、LINEは2011年6月に公開されてまだ1年しか経っていない。しかし全くの新規アプリ・サービスでそれだけの期間に4000万人が登録したコミュニティというのは他に例は無いだろう。
OGC2012のNHN Japan自身の講演によれば、 会員2000万人突破にかかった期間は256日であり、これはTwitterの1035日・Facebookの1152日に比べても驚異的と言えるだろう。
無論こうした爆発的な人気の原因には、そもそものコミュニケーションツールとしての使いやすさ・取っつきやすさや、無料であること、TVCMなどのマーケティングなども大きな要因であろう。
しかし僕はそこには、これまでどのサービスも乗り越えてこなかった大きなポイントがあると思う。
それは「ネットワーク構築のショートカット」である。
随分間が空いてしまいましたが、やはりまとめておくことにします。
前回までにドコモへ問い合わせた内容はこちら。
世間的にもこの問題は下火になっており僕もそれで構わないとも思いますが、質疑応答の過程で幾つか意義のある論点もあり得たかと思いますのでそれを中心にまとめます。
何が事実だったのか、あるいはドコモの主張だったのか
IMEI(International Mobile Equipment Identity)は個々の端末固有に紐付けられるユニークなIDで「携帯キャリア(電話会社)により端末の識別を行う」際に利用されるIDです。通話時やデータ通信時には常に送出されており携帯キャリアは把握することが出来ます、例えば盗難端末が携帯網に接続される場合にそれを拒否して使えなくする、などの使われ方をします。
IMEIは端末の恐らく電池パックの裏などにも印字されていますしまた箱にも書かれていることも多いです。またそもそも皆さんが携帯端末を契約した際にはキャリアでどの契約者にどのIMEIの携帯を売ったかは当然記録されており(つまり契約者と紐付いている)例えば契約書には電話番号と同時にIMEIの記載されているはずです。(但し中古品を買ったなどの場合はこの限りではありません)
このような目的ですので携帯キャリアがIMEIを把握したり利用することは想定内の利用方法です。しかし今回恐らくは初めてIMEIがキャリア以外のC/Pへ通知されることになった、ことがこれまでの使われ方とは異なる大きな問題なのです。これはIMEIの定義やこれまでの通信事業者の論理からすれば世界的にもかなり驚くべき事例かと思います。簡単に言うと何とも安直にIMEIを「目的外利用」することになったものです。
つまりIMEIというキャリアにとっては契約者に紐付くIDがC/Pへ通知されることでC/Pではこれを用いてユーザーをユニークに見分けることが出来るようになります。また悪意を持って見れば、複数のC/Pがキャリアに内緒でデータを持ち寄ってデータの突き合わせをし、より完全で詳細な個人情報を組み立て上げ売買したりシェアし合うかも知れません。IMEIは決して変動するIDではありませんのでほぼ未来永劫に渡って一度紐付けられたあなたの個人情報は業者から削除されたり無効になることは無く、例えばどのサイトへも少しアクセスしただけでもあなたが一体何者で他のサイト含めてこれまでどんなコンテンツを購入したり閲覧したか、などが丸わかりになる可能性も出てきます。再度繰り返しますが、これが未来永劫続きます。
これが所謂「固定ID」の危険性であり、「名寄せ」と呼ばれる個人情報収集手法です。
まとめると、本来携帯キャリアの管理下にしておくべきIMEIが外部で利用されてしまうこと、上記で述べたように固定IDによる名寄せリスク(プライバシー)が懸念される問題と言えます。
これは微妙です。
但しメディアプレイヤーのみの送信、それもライセンス取得時のみと言うことからは、常に全てのC/Pで行えることでも無いでしょう。これはライセンスサーバーをきちんと立てて運用するにはそれなりに運用コストもかかり、ただ個人情報を取得するだけの目的では簡単には行えないと考えられるからです。保証は出来ませんしもちろんそうした運用を行った上で悪意を持って名寄せをするC/Pがいない保証もありませんが、例えば当初懸念されていたように「ブラウザが無条件でIMEIを送信する」事態に比べればリスクはよほど低いとは言えるでしょう。
また現在普通に行われているように、サイトで簡単にやはり同じように契約者を固定IDで特定できるiモードIDが取得できてしまうことに比べればよほど問題は小さいです。
但しこうしたリスクは少ないながら付きまとっていることはしっかりと把握しておきましょう。
質疑応答からもドコモは「固定IDのリスクについては承知している」と繰り返していました。しかしながらにも関わらずこのように安易にIMEI(固定ID)を利用してしまうのは、もちろんC/Pへの配慮という大きな問題はあったと思いますが、同時にIMEIなど固定IDに変わるソリューションをきちんとC/Pに提供できなかった「プラットフォーマーとしての責務の欠如」に大変懸念を感じます。
これは別エントリーにて後日もっと詳しく述べられるといいなあとも思うのですが、簡単に言えばドコモがプラットフォーマーとして利用者の期待に応えられず、C/Pの要望にただ流されているという懸念すべき状況であるとも言えるでしょう。
これはアップルが同様にプラットフォーマーとしてどのような施策をしているかと比較してみればよくわかるでしょう。
現在の大きな潮流の変化(スマフォへの移行や世間のプライバシー問題の関心の変化)にドコモ自身が付いていけないことを露呈した、あるいは白旗を揚げている事例では無いかと思います。
今後一点注意しなければならないと思うのは、今回の事例が前例となって、「端末固定IDはライセンス取得・コンテンツ保護のためには必須」という理由が「錦の旗」化してしまわないか、という懸念です。
当然アップルやアマゾンの例を見て分かるように、端末に紐付いた固定IDは別にコンテンツ・ライセンスのための必須条件ではありません。
しかし少なくとも日本のデジコン業界では「ライセンスは端末に紐付いたIDでしか守れない」神話が根付いてしまっているようです。そしてまたユーザーも簡単にそれを(その先のリスクを理解していないので)受け入れてしまっている事実があります。
ライセンス取得と端末固定IDは全く別なのだ、ということはぜひとも広く理解して欲しいし、実のところこうしたことはデジコン業界がユーザーに問題を押し付けて自分たちが楽を出来るからに他ならない、と言う点は理解しておきたいと思います。
—
ドコモからの回答では「きちんと利用者に固定IDの危険性を啓蒙していきたい」との段がありました。またこの問題がどのように変貌していくかは実際に運用が始まらないとわからない点もあります。
当面の問題は少ないにせよ、今後とも興味を持って注目していきたいし皆さんにもお願いしたいところです。
この記事はauのEZWebがそろそろ終了しそうな件の続編です。
当該記事では「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」ことから場合によってはEZWebの課金システムや一部認証が脆弱性に晒され得るのではないかと危惧したのだが、もしかすると本当に現在それが起きていた(いる)かも知れない。
F001（PCサイトビューアー）※一部伏せ字
あれ？REMOTE_ADDRが111.87.241.##？
これ、2011年秋冬モデル以降の一部機種のEZブラウザ/PCSVのIPアドレス帯域じゃないですね。
従来のPCサイトビューアーのIPアドレス帯域でもありません。
EZWebとPCサイトビューアーのIPアドレス帯域が具体的にどんなアドレスになるかは上記の通り既に公表されているのだが、どうやら現在PCサイトビューアーからアクセスすると全く別のアドレスになっているようだ。つまり以前からのアナウンスにも関わらずEZWebとPCサイトビューアーのIPアドレス帯域は統一されておらず別のものになっているようだ。これは何を意味するのか。
auの2011年秋冬モデルである「F001」のHTTPヘッダが従来機と比べて大きく変更になっているようです
通常のEZwebブラウザとPCサイトビューアーのIPアドレス帯域が統一された関係で、PCサイトビューア＋JavaScriptを使っての値のねつ造ができないかどうかが気になります。
上記の記事を見ると、本来来るはずのない帯域からアクセスが来ているとのことなのですが、この辺りの問題が解決できてなかったからとかではないでしょうね。。。
恐らくk-tai.orgさんの予想か当たっているのではないだろうか。
これは想像だが、当初はもちろんEZWebとPCサイトビューアーのIPアドレス帯域は統一されたのだろう。しかしPCサイトビューアーでEZWebのHTTPヘッダーのケータイID(個体識別番号、サブスクライバーID)を偽装できる問題が発覚してしまったのでは無いだろうか。
そのため少なくとも一時的にでも問題を回避できるように、PCサイトビューアーのIPアドレス帯域をEZWebとは急遽別にしたのではないか。
以前の記事からも繰り返しになるが、ケータイIDを脆弱ながらもぎりぎり安全に保つには一般に三つの条件がある。
(1) そのアクセスがそのキャリアの携帯網(IPアドレス帯域)からのみであることをサービスプロバイダーが保証すること
(2) 携帯網ではケータイIDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くしてケータイIDの偽装などの可能性をできるだけ低く保つこと
このうち2についてはauでは採用されていない可能性がある。そして今回PCサイトビューアーとIPアドレス帯域を統一することで1でサービスプロバイダー側にてEZWebからだけのアクセスでありHTTPヘッダーのケータイIDをそのまま信じていいのかどうかは微妙になった。後は3の条件のみが頼みの綱となった。
すなわち「PCサイトビューアーからケータイIDを偽装して付加できることがあっては絶対にならない」のだ。もしそうなってしまえばケータイECの信頼性は崩壊する。
しかしながら、それが今回偽装できることが発覚してしまったのでは無いだろうか。
以上はあくまで想像に過ぎない。またとりあえずPCサイトビューアーのIPアドレス帯域が緊急的に変更されているのなら差し迫った危機は回避されている。
そこで以下のような公開質問をauのカスタマーサポートへ行ってみた。
「PCSVのIP帯域とセキュリティについて」 表題についてご質問です。 1. 今秋冬モデルからEZWebとPCSVのIP帯域が統一されるとのアナウンスがありますが http://j.mp/vzi7QB http://j.mp/tG3hDj こちらの記事 http://j.mp/uEniDb によれば実際には記載の無いアドレスからPCSVはアクセスされているようです。 これは事実ですか？事実である場合理由は何ですか。 2. どこかでこれらはアナウンスされていらっしゃいますか。 3. http://j.mp/v4AqrD では「PCSVにてHTTP_X_UP_SUBNOの偽造が可能なのでは」との推測がされています。 私も同様の疑いを持ちますが事実関係はいかがでしょうか。 4. 3が事実であった場合、現在まで告知がされていません。それは何故ですか。脆弱性は隠したいとの意図でしょうか なお本件は公開質問として送付させて頂いております。ご回答に付き適時適切に公開させて頂く場合があります旨ご了承下さい。 以上、お忙しい中大変恐縮ではございますが、ご回答頂けましたら幸いです。どうぞ宜しくお願い致します。
(なお質問がつっけんどうで分かりにくく感じられると思うが、これはauの問い合わせフォームが上限500文字で最低限まで文字数を削る必要があったためだ。せめて1000文字ほどあればもう少し丁寧に書けるのだが…)
結果が帰ってくればまたご報告したいと思う。
以前脆弱性公開ポリシーについてauへ質問した際には、「システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する」「セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している」と回答頂いているので、仮に事実であれば問題解消後には必ず公表されるだろうし、また少なくともF001ユーザーやコンテンツプロバイダーには事後報告がされるはずだ。今回の件はその試金石となることだろう。
事実であったとして、F001にはセキュリティアップデートが行われるかも知れない。しかし全ての端末がアップデートをするとも限らない。とすればIP帯域の統一は簡単には戻せないかも知れない。果たしてどのような改修が行われ得るだろうか。
今後その点にも注目しておきたいと思う。
追記(2011/11/23)
Kimuraさんの検証によれば、F001のPCサイトビューアーではJavaScriptでUserAgentおよびX-UP-SUBNOの変更や追加は出来なくなっているとのこと。(以前の機種では出来た)
F001のPCサイトビューアーでsetRequestHeader
こうした仕様はIPアドレス帯域を統一する以上想定内(大前提)の仕様なのだが、にも関わらずIP帯域が分けられていると言うことは、これを回避して変更・追加する方法が存在するということになりますね
追記(2011/11/28)
KDDIから回答が来ましたが、「PCでもPCサイトビューアーでもHTTPヘッダーの書き換えが出来るのは当然のこと」「セキュリティ確保のためEZWebとPCSVのIPアドレス帯域は分離している」のだそうで・・。この自分で整えたちゃぶ台をひっくり返す回答はどうしてくれようか、混乱中です･･･。
因みにEZfactoryのお知らせとIPアドレス帯域に変更がされましたね。何やらこれまでアナウンスしていた「EZWebとPCSVのIPアドレス帯域の統一」が無かったことにされているのですが・・？？
とりあえずこういう質問にしておいた。
以前よりKDDI様では「2011年秋冬モデルよりEZWebとPCSVのIPアドレス帯域は統一する」とアナウンスされていらっしゃいましたが、 下記ご回答とEZfactoryを拝見する限り、これらが無かったことになっているようですね。 今後ともEZWebとPCSVのIPアドレス帯域は恒常的に分離されたままになる、ということでしょうか。 またずっと以前よりアナウンスされていた内容がここに来て突如変更された理由は何でしょうか。私が指摘させて頂いていたように 「当初統一する予定だったが、本来変更できてはいけないX-UP-SUBNOがF001のPCSVでは変更できてしまった脆弱性(または仕様抜け) が発覚したため、予定を変更してIPアドレス帯域を分離することにした」との理由しか思いつかないのですが、いかがでしょうか。 仮にこれが事実であれば全ユーザーが影響を受けるセキュリティ問題であった訳ですから、お立場のある通信事業者としては 隠蔽するのでは無く明白に公表されるべきと思いますが、いかがでしょうか。
追記(2011/11/29)
徳丸浩氏から今回の脆弱性の詳細について公表されました。
KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された
端的にはPCSV単独の脆弱性ではなく、PHPなど特定言語との組み合わせの問題ですね。しかし結果として脆弱性として「合成」されてしまう訳で･･･。悩ましいですね。ただ当面は回避されていること、かんたんログイン時のみの問題であることはまだ幸いであるとも言えるでしょう。
追記(2011/12/03)
遅くなりましたが、11/30に上記質問に対してauより返答がありました。
「敢えて」そのまま回答を掲載します。
IPアドレスの帯域は恒常的に分離しておく予定です。 以前よりアナウンスしていた内容を変更した理由は、セキュリティ確保のためです。 セキュリティ確保のために、IPアドレスを分離したことは既に公表しております。 詳細につきましては、セキュリティの観点から回答は差し控えさせていただきます。
とのことです。
この回答への評価についてはまずは皆さんにお任せしますが、後日別途エントリーを上げるかも知れません。
(2011/11/19 更新)
(2011/11/18 更新)
(2011/11/11 更新)
(2011/10/29 更新)
取り急ぎ、一般向け窓口宛ではありますが個人的に以下のような公開質問状を送付しました。
やり取りが発生しましたら追記していきます。経験上、最初の回答までには一週間はかかると思います。。。
お世話になります。 先般貴社WEBサイトにて今秋のスマートフォンに搭載されるメディアプレーヤーよりアクセス時のUserAgent情報にIMEIが 付加されるとの発表がありました。 参考: http://j.mp/nJWr9k これに関しまして以下ご質問させて頂きます。 1. IMEIをUserAgentに付加されることにした意図・目的は何でしょうか 2. 一般にこうしたIDに変動が無く恒久的に容易にユーザートラッキングできる問題はプライバシー上「Super Cookie」 (参考: http://www.horibemasao.org/takagi.ppt3.pdf)問題として広く知られておりますが、こうした問題について 今回どのような検討をされましたか 3. こうしたSuper Cookieが標準で搭載された場合、本来単独では個人が特定できないはずの情報が完全な個人情報として 容易に流通する可能性が高くなります。こうした問題に対してどのような対策を講じようとされていらっしゃいますか。 4. 上記の通り、コンテンツプロバイダー(公式サイトに限りません)はこれまではほぼ不可能だった利用者端末のIMEIを 容易に入手できるようになる訳ですが、これは問題あると考えていらっしゃいますか。あるいは無いとお考えでしょうか。 いずれかにおいて、その理由は何でしょうか。 5.テレビ新聞で報道されている通り「ユーザー同意無く端末情報を取得するスマートフォンアプリ」が複数見つかり スパイウェアと批判を受けたり更に不正指令電磁的記録取得罪に問われるのではないかとの報道もあります。 これは利用者にアプリケーションの動作を正確に説明していないためですが今回の仕様について利用者にどのようにまた どの程度のご説明をされていらっしゃいますか。 6. プライバシー問題が大きくクローズアップされている現在、今回のような仕様の導入は早急に中止すべきと個人的には 考えますが、中止されるあるいは検討されるご予定はございますか。 以上です。 なおこの質問は公開質問であり、インターネットなどによって一般に公開される旨、あらかじめご了承下さい。 またご回答はひとまとめではなく、上記一問に付き一答ずつお願い致します。 以上、大変お手数ですがご回答賜りますようどうぞ宜しくお願いします。
ドコモからの回答がありました。
コメントにもありますように、その後ドコモは「IMEIはメディアプレーヤーがライセンスを取得する際のみ」であることを公表しており回答もそれに沿ったものになっています。
以下、回答を簡単にまとめます。
ポイントは「IMEIはC/Pサイドにも送信されうる(模様)」「ユーザー許諾を取るので問題無い」としている点となるでしょうか。
当方より再度以下の内容で質問をしました。
お世話になっております。お忙しい中ご回答頂きまして誠にありがとうございました。 下記拝見させて頂きました。その上で追加にてご質問させて頂きたく、再々申し訳ありませんがご回答願えませんでしょうか。 お手数ですが前回と同じく、ひとまとめではなく一問一答にてお願い致します。 なお下記にもご回答頂いております通り、貴社WebサイトにてもIMEI送信はメディアプレーヤーでのみとなっている旨 記載が変更されている点は後日拝見致しました。 1. IMEIをPlayReadyでの端末特定のためのDRM管理キーにされている(あるいはその予定)とのことと理解致しましたが、 これはマイクロソフト殿での仕様でしょうか。若しくはドコモ殿の判断ですか。 2. 端末判別に何故IMEIが必須でしょうか。一般によく知られている手法のように、例えばUUID(C/Pごとに異なるキー。 PlayReadyで言えばドメインごとに異なるキー体系)でも十分なのではありませんか。IMEIで無ければならない積極的な 理由はありますか。 3. メディアプレイヤーの仕様としては、ドコモ殿のサイトへ接続する場合のみIMEIを送信するのでは無く、 例えばC/P殿が独自に設置された(つまりコンテンツが指定した)ライセンスサーバーでも無条件でIMEIは送信される、 ということでしょうか。 4. 3がYESの場合、全くドコモ殿が預かり知らないところでもIMEIは取得可能になろうかと思います (例えば「勝手サイト」など)。その場合、ドコモ殿がコントロールできることでは無い以上、「IMEIを広く収集される 危険性はない」ということはあり得ないと思われますがいかがでしょうか。 5. 重ねての質問にもなりますが、「ユーザー許諾を取っている」とのことですが、具体的にはどのような周知にて お客様へお伝えされていますか。例えば、そもそもほぼ全ての一般のお客様はIMEIが何であるのか、名寄せのリスク とは具体的にどのようなことなのかはほぼご承知では無いでしょう。そこを十分理解して頂かずに形だけ許諾をとっても 実質が伴わなければオプトインでは無いというのがプライバシー上でも民法上でも一般的な考え方です。 先の「スパイウェア」とされたアプリでも形だけの許諾を前提にしていたため、スパイウェアとして理解されるように なりました。 その前提で、どのようにユーザーへの啓蒙と理解を図られようとされていますか。 6. IMEIのように恒久的に値が変わらずユーザーを特定し続ける所謂「固定ID」については容易に個人情報と 結びつけやすいことから、個人情報として取り扱うべきだ、とのセキュリティ研究者からの意見もあります。 参考: http://www.atmarkit.co.jp/news/analysis/201110/27/smartphone.html この点に関し、ドコモ殿のご見解をお聞かせ下さい。 以上です。 なお最後に、「メールの一部または全部を転用したり、二次利用することはご遠慮いただ」きたいとのことですが、 どのような根拠・理由によるものでしょうか。 既に十二分にご理解されているのでは無いかと察しますが、本件は現在ネット上含め大変注目されている 「利用者プライバシー」に関わる問題であり、社会的意義の大変大きな問題です。故に最初のメールにても 申し上げました通り「公開質問状」として送付させて頂きました。 ドコモ殿のご見解を適切に引用・周知することは社会公益の点からも大変重要と考えており、随時適切かつ適正に 引用・周知致します旨、何とぞご理解下さい。 以上となります。 お忙しい中大変恐縮ですがどうぞご回答賜りますよう、宜しくお願い申し上げます。
以下、ドコモからの回答の要約です。
—————————————————————-
ライセンスを取得しますか？
ライセンスの取得時には通信が発生します。
また、その際、携帯電話の識別番号（IMEI）が送信されます。
はい／いいえ
—————————————————————-
当方より再々度以下の内容で質問をしました。
お世話になっております。お忙しい中、ご回答誠にありがとうございました。 再々申し訳ございません。 下記ご回答を受けまして再々度ご質問させて下さい。 1. 念のためご確認させて下さい。「IMEIを送出しないことも可能な仕様」とは許諾画面で許可しないことで、 そもそもライセンス取得を行わない、ということを意味していらっしゃいますか。ライセンス取得には行くがヘッダーに IMEIは付加しない、という意味ではありませんよね？ 2. CPのライセンスサーバーではどのような仕様かは分からないものの、IMEIを送出する仕様となっている、 との理解で宜しいでしょうか。つまり実際のライセンス確認方法はCPさんにより異なるということですね。 3. これは個人的な意見ともなりますが。IMEIの送出はそもそもCPさんへのやむにやまれぬ配慮であり、 またプライバシーへの危険性についてもユーザーに今後具体的に周知・啓蒙されていくと言うことでは理解しました。 特にユーザーへの周知はぜひ形だけに終わらず具体的な施策を期待致します。 その上ででもですが、やはりIMEIの送出は正当化できるものではないと考えます。理由は既に貴社にても把握して いらっしゃる通り、「固定IDとユーザー情報の紐付け」を前提とした仕様はいかなる予防策を講じるにせよ プライバシー上のリスクは制御できないからです。 恐らくはCPさんからの根強い要望もあった故であり本来であればドコモ様としては避けたかった事態では無いかと 推察はしますが、今後プラットフォーマーの役割としてはそうしたCPさんらがIMEIを使わずともUUIDなどでうまく 運用できる仕組み(例えば永続的にIMEIを使い続けなくともどこかの段階でUUIDや一般的なユーザー認証へ移行する ことは技術的には可能でしょう)を提供される、あるいはそう誘導されるのもドコモ様の責務のうちでありユーザーへの 責任では無いかと思いますが、いかが考えられるでしょうか。 4. 固定IDの利用についてはリスクがあることを重々承知してらっしゃることはよく分かりました。 しかし一方で、これはIMEI送出だけに限らず、例えばやはり同じく永続的なキーであるiモードIDでも同様かと思います。 更にはiモードIDの場合はほぼ無条件ですべてのCPさんにて取得可能であり(通知可否は選択可能なものの)、 更に昨年よりスマートフォンでも取得可能となっています。 こうした状況を前提にお聞きしたいのですが(但しiモードIDに限らず固定ID送出の取り扱い全般として)、 下記にて「法令遵守・監督官庁指導に従う」「ユーザーへの注意喚起」を述べていらっしゃいますが、 そうしたリスクを捉えつつ利用を継続されるのは施策として矛盾していませんか。 3とも関連しますがプラットフォーマーの立場において、固定IDについてはどのようなポリシーにて運用されようと していますか。将来廃止への方向性の意図はお持ちになられますか。 5. 固定IDを如何に安全に取り扱うべきか、またどのようなリスクがあるか、CPさんにせよユーザーにせよ、 具体的にどのように啓蒙・周知をされていく予定でしょうか。例えば勝手サイトを含めてCPさん向けに固定IDの取扱規則や ベストプラクティスを公表する、ユーザーにiモードIDなどの固定IDにどのようなプライバシー上の危険性があるかの これまで以上に踏み込んだ啓蒙など、予定されませんか。 ドコモさんでのそうした姿勢こそがスマートフォンを中心としたケータイ・ネットワークへの信頼性を高めるものであり、 隠し続けることは逆に疑念しか生み出さないと考えるものですが、どのようにお考えになるでしょうか。 最後になりますが、必要に応じたネット上での引用・周知については十分に適正・適切に行わさせて頂きますこと、お約束させて頂きます。 以上です。長々と申し訳ございません。 お忙しい中大変恐縮ですが、ご回答賜りましたら幸いです。 では、どうぞ宜しくお願い致します。
基本的には、まず問い質したかった「固定IDへの考え方・取り扱い方針」については回答拒否ですね。まあもう固定IDを送出しているのは事実なので答えにくいでしょう。但し懸念の表明という点では達せたかなと感じています。
ドコモ的にはこのあたりが限界なのでしょう。
別途、質問ではなく要望という形で先方には伝えて本件はとりあえず取り纏めということになるかと思います。
まとめとして以下を送付しました。
ご回答ありがとうございました。 全てのご質問に付き明確なご回答頂けなかったのは残念ですが、ご事情はお察し致します。 ご質問という形でさせて頂いて参りましたが、本日はドコモ様に対する「ご要望」として以下お聞き頂ければ幸いです。 1. 固定IDに関しての利用者への啓蒙 既に述べられていらっしゃいますように、今後注意喚起などの啓蒙を行われるということで期待しております。 現状固定IDでのプライバシーリスクについてはキャリア様から発信された情報はほぼ無く、 主に民間のセキュリティ研究者や団体が発信する内容ばかりです。キャリア様としてしっかりと正確に啓蒙・ 注意喚起されることを期待しております。特に、正確に事実を利用者が理解しない限りはどのような許諾を得ようと、 恐らく法的にも意味をなさない点にはぜひご留意頂きたいと思います。 2. プラットフォーマーとしてのCP様への指導 あくまでCP様は対等のお立場のビジネスパートナーであることは承知の上で申し上げますが、 これまで頂いた回答をまとめると、結局のところはCP様が固定IDによる名寄せや利用者の了承を得ない 情報取得があれば、如何にドコモ様が「リスクをできるだけ低くしている」と主張されても全く意味を なさなくなってしまうことはご理解されているかと思います。 つまり如何にして、利用者と同じくCP殿(勝手サイト含む)を教育し啓蒙していけるかが、 「リスクをできるだけ低くしている」との主張を現実的なことにできるかの鍵かと存じます。 こうした仕組みを広く提供されている以上、ドコモ様がどのようなお考えであろうとも世間では ビジネスモデル全体に責務を負うべき「プラットフォーマー」として見なされるべきかと思います。 自由にCP殿にビジネスをして頂くことは重要でしょうが、一方でCP殿に「正しく」ビジネスをして 頂くように仕向ける責務をドコモ殿は負っていらっしゃるのだと考えます。 また例えば固定IDが必要と主張されるようなCP殿にはドコモ様自ら必要なくとも実現可能な ソリューションを提供されるなど、そこまでのご認識と責務は負われるべきかと思います。 で無いのであれば、それは所謂「土管業」と何ら変わらなくなるからです。 こうした点が欠けていたからこそ所謂「かんたんログイン」の問題は起きましたし、 それを解決させたのはプラットフォーマーであるはずのドコモ様では無くまたCP殿自らでも無く、 市井のセキュリティ関係者の啓蒙でした。 しかしそうした「異常な」状況をこれ以上続けるべきではありません。 3. 固定IDが前提となるビジネスモデルの廃止と移行 一点ぜひ認識して頂きたいのは、これらプライバシーやセキュリティのリスク(たとえ低い可能性で あるとしても)を背負うのはドコモ様でもCP殿でも無く、利用者自身だということです。 しかも利用者にそのリスクを避ける選択肢はほぼありません。 これは1,2とも関わることですが、故にプラットフォーマーとしての責任は重いと言わざるを得ません。 IDに関わるソリューションとしては様々取り組まれていると思いますが、固定IDビジネスは一般的に、 これまでのフィーチャーフォンのような「閉じた世界」では有用であったとしても、 スマートフォンが前提とする素のインターネットの世界では非常に脆弱です。 これは十二分にご承知の通りかと思います。 しかし未だ固定IDに引きづられるビジネスモデルがあるのだとすれば、スマートフォンへの移行という この絶好のタイミング無くして廃止と移行のタイミングは今後存在しないでしょう。 ドコモ様ではiモードIDという古い固定IDビジネスの一方で、ドコモIDというインターネットとの 親和性の高い技術モデルもお持ちになっており、決して不可能なことでは無いと感じています。 繰り返しになりますが、これは選択肢を持てない利用者保護の観点からも、 強くドコモ様自身が推進されるべき方向性では無いかと存じます。 以上となります。長々と失礼致しました。 ぜひご検討頂き、技術関係者様・ビジネス関係者様含めて、上記ご回覧頂ければ幸いです。 またご意見・ご回答なども頂ければ嬉しく存じます。 末筆ながら貴社の益々のご発展をお祈り致しております。 以上、ありがとうございました。今後ともどうぞよろしくお願いいたします。
とりあえず一連の質問は終了とします。
別途まとめのエントリーを後日アップする予定です。
7月になってsecure.softbank.ne.jpという一種のSSLプロキシの廃止を受けて、高木さんと徳丸さんから続けて背景説明のエントリーが発表されている。
SoftBankガラケーの致命的な脆弱性がようやく解消
ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る
簡単に言えばこのSSLプロキシの廃止は重大なセキュリティリスクを回避するために絶対的に必要だったと言うことなのだが、詳細はぜひ上記を参照して欲しい。
正直に言うと、この高木さんとソフトバンクモバイル宮川氏のやり取りの前に少しきっかけに関わったので興味を持ってみていたのだが、当初は発端となったアプリ側でのCookieの取り扱いにくさ以上の感触を得ていなかった。
それが違うなと思い直したのは両名が7月を前に盛り上がりだしてからで(笑)、それが同一生成元ポリシーに関わる問題であろうことはその後すぐ気付いた。
しかし実は水面下では、端末のJavaScriptを調整してsecure.softbank.ne.jpでの挙動のみ変更したいたことなどは今回のエントリーで始めて知った次第だ。
アクロバティックな対応だなと思うし、非常に感じるのはこれまで閉塞した世界でなら何も考えずとも良かった問題がJavaScriptやあるいは通信路の解放などといった「オープン化」によって大きく揺らいで行くであろう未来の姿だ。
先のエントリーで徳丸氏は以下のように述べている。
この事例から言えることは、（ガラパゴスと表現されることもある）日本の携帯Web独自の仕様というのものが非常にきわどく、もろいものだということです。
携帯Webの仕様がオープンにならないことも問題です。私は前述のJavaScript等の仕様を調べるために、公開されている仕様書だけでは十分でないために、実機での試行錯誤が必要でした。携帯Webの安全性確保のため、開発者やセキュリティ研究者に向けた十分な情報開示を希望します。
僕も全く同意見だ。
そもそもの問題はあまりに日本のケータイWEBがガラパゴスと言われるような独自進化をし、それはクローズドだったからまだよかったものの、ここへ来てスマートフォンに始まり、JavaScriptなどブラウザがリッチ化しOSはAndroidなどよりオープンなもの(逆に言えばキャリアやメーカーが手を加えにくい) となり、また通信路はWi-Fiや定められた端末しか繋げられない閉塞したものではなくPCなどと同居するよりオープンなものへと変貌しつつある。
日本のケータイシーンはただ端末がガラケーからスマートフォンへ置き換えられているだけではない。技術的な観点からすると「一般的なインターネット」へ変貌つつある。
問題はそうした急速な変化の中で果たしてキャリアはこうした旧世代の脆い仕様との乖離に伴う脆弱性に正しく対応可能なのか、ということだ。
少し古い話になるのだが、実は半年ほど前個人的に一ユーザーとして各キャリアに以下のような質問を行ってみた。
1. 具体例は示しませんが、近年携帯電話やスマートフォンに関して、セキュリティ上の脆弱性がネットなどで指摘されることが多くなってきました。
この1年間において御社にて脆弱性が発覚または発見しこれを修正などの対策をされた実績がありますか。ある場合、もし宜しければ具体例をお教え下さい。
2. 1のケースに関わらず、一般論で結構なのですが御社では脆弱性が発覚した場合修正し対応なさいますか。対応する/しないの判断基準はどの点だと認識していらっしゃいますか。
3. その場合、脆弱性があった旨ユーザーに情報を開示されますか。
4. 御社にてこうした脆弱性対応のためのポリシーを策定し運用されていらっしゃいますか。またそれは公開されユーザーへ周知されていらっしゃいますか。
各社様々経緯があり返答に時間もかかり結局一ヶ月近くかかった覚えがあるのだが、簡単にまとめると各社の回答は以下のようなものだった。
| 質問事項 | 脆弱性が発覚または発見しこれを修正などの対策をされた実績はあるか | 脆弱性が発覚した場合修正し対応するか。対応する/しないの判断基準はどの点だと認識しているか | 脆弱性があった旨ユーザーに情報を開示するか | 脆弱性対応のためのポリシーを策定し運用しているか。またそれは公開されユーザーへ周知されているか |
| ドコモ | 特に回答無し | – ウィルス対策、パターン更新などの対策を行っている – 対策の判断基準は脆弱性の程度や影響などを総合的に判断 |
– お客様にお伝えできる情報は弊社ウェブサイト等にて公開させていただきますことをご了承ください | 特に回答無し |
| au | – 脆弱性事例はあり(最近の例を例示) | – システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する | – セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している | 特に回答無し |
| ソフトバンク | 弊社の機密事項に関するものとなるで社外への情報開示はWEBサイトで公開している内容のみでそれ以外は答えられない | |||
| イーモバイル | 特に回答無し | 特に回答無し | – お客様に影響を及ぼす問題が発見された場合には、すみやかに情報を開示し対策を実施することとしています。 情報の開示方法は、弊社ホームページ上に掲載するケースや、 個別にご連絡する場合など案件によって最適な方法で実施いたします。 |
特に回答無し |
多少の違いはあるが、どれも判で押したような特に具体性のない内容であることは間違いないだろう。
注目すべきはどこのキャリアも回答には数週間から一ヶ月かかっている、つまりあらかじめ想定している内容ではなく、 社内調整した結果の回答であったのだろう。それは脆弱性ポリシーの有無の質問に対していずれも明確な回答がなかったことからも察しが付く。
つまりは各社とも今回のような脆弱性への対処については明確な社内規定やルールがあり運用されている訳ではなく、発覚した場合のケースバイケースということなのではないだろうか。
これは一言で言って常に対処が後手に回り対処療法に陥りやすい危険な兆候とも言えるだろう。
「フルディスクロージャ」という言葉がある。これは「脆弱性情報を隠蔽しこれを知り得ている一部の悪意あるユーザーに悪用されるよりは、脆弱性情報を発見したらすぐに広くオープンにして全てのユーザーに完全に周知した方が安全だ」という考え方だ。
これはこれで極端な考え方で、例えば0Dayアタックと呼ばれるような一般ユーザーにこのような脆弱性から守る術を持たないうちから攻撃されるリスクが十分あるからだ。
そこまで極端なフルディスクロージャーは近年では採用されることは少ないが、しかし一方で上記のようなキャリアの態度というのは、これまた極端な「隠蔽体質」と言われても仕方ないだろう。
しかし実はこのフルディスクロージャーの考え方には、インターネット黎明期に脆弱性の隠蔽が頻繁に行われ、その結果被害が拡大した結果、反省と反発からの一種の極論から生まれたという背景がある。
キャリアが理解しているかどうかは分からない。しかし僕にはこれまでのキャリアは閉塞網と完全に制御された端末でのうのうと暮らしてきた「井の中の蛙」に見える。
スマートフォンの伸長は歴史の針を一気に進め、蛙を大海へ叩き込んだ、とも言えるだろう。
彼らが今後暮らさなければならない「本当のインターネット」の大海では、脆弱性情報は共有され適切に管理され、インターネット全体の安全性のバランスを取る仕組みと常識感が既に熟成されている。それはインターネットの巨大なプレーヤーとしてはほぼ責務と言っていい。 だがそんな「本当のインターネットでの常識」に付いていけるだけの力を身に付けられているだろうか。僕は甚だ疑問だ。
キャリア各社は今後スマートフォンへ軸足を移し、また「普通のインターネット」を提供したいと発言している。一方で各キャリア毎に課金・認証の仕組みを導入しようとしており、ドコモはiモードを、auはau one IDをすでにAndroidに組み込んでいるようだ。
けれど彼らは本当にそれらがインターネットの大海でどういう意味を持つか理解して実現できるだろうか。
僕はこうした脆弱性ポリシーや、インターネットでは当たり前の技術情報の周知1つ出来ていない現状では結局同じことを繰り返し、更に酷いセキュリティ問題を繰り広げる未来としか思えないのだ。