[Analysis]
スマホアプリとプライバシーの「越えてはいけない一線」
2011/10/27
スマートフォンアプリは果たしてどこまで、端末に関する情報を取得してもいいのだろうか。
位置情報と連動してお勧め店舗情報を表示したり、過去の検索履歴を基に商品を提案したりと、端末の情報やユーザーの行動履歴を活用するスマートフォンアプリが登場している。中には便利なものも多いが、一歩間違えれば、ユーザーのプライベートな情報が筒抜けになりかねない。結果として、スマートフォンを活用したビジネスやそれを支える広告市場までもが、否定的な目で見られ、発展を阻害される恐れもある。
この議論が起こったきっかけの1つは、ミログが公開していた「AppLog」と「app.tv」というアプリだ。AppLogはSDKの形で提供され、これを自前のアプリに組み込むと、Android端末にインストールされているアプリの情報やその起動回数を収集し、同社のアプリケーション分析サービスに送信するようになっていた。開発者にはインストール数に応じて、収益が還元される。
一方のapp.tvは「動画コンテンツ視聴アプリ」として配布されていた。アニメなどの動画を配信する一方で、バックエンドでAndroid端末の個体識別番号やAndroid OSのバージョン、機種名に加え、端末にインストールされているアプリケーション一覧や起動履歴一覧などの情報を収集し、ユーザーの許諾を得ずにミログに送信する仕様となっていた。
ミログでは、こうした行為はプライバシーに反するものとの指摘を受け、10月10日にいずれのサービスも停止した。そして10月26日夜になって、AppLogSDKに関するすべてのサービスを中止し、これまでに収集したデータを破棄すると発表している。
越えてはいけない一線はどこに?
とはいえPCの世界でも、Cookieを用いてユーザーのWeb閲覧履歴を収集し、それを基に最適化した広告を配信する「行動ターゲティング広告」は広く行われている。ミログのケースもその一種ととらえることはできないのだろうか。なぜ、端末の情報を収集して送信することが問題になり、サービス中止にまで至ったのだろうか?
産業技術総合研究所 情報セキュリティ研究センター 主任研究員の高木浩光氏によると、取得する情報の範囲が「自分の広告ネットワークの範囲かどうか」に、越えてはいけない一線があるのではないかという。
PC向けのWebの世界では、まず、自社サイト内で完結する形でユーザーの行動を追跡することができる。もしそれがイヤならば、ユーザーはそのサイトを避けて通ることができる。
第三者Cookieを利用した「アドネットワーク」が使われることも多い。広告配信会社は、自社のアドネットワークに参加している複数のサイトに広告を配信する。その際、多様なWeb媒体の中で広告配信を最適化するために、行動ターゲティングが使われてきた。
しかし、「アドネットワークが情報を収集するのは、広告を張っているサイトに関するものだけで、それ以外の広告を張り巡らしていないサイト、無関係なサイトの履歴までは取っていない」(高木氏)。
これは技術的な限界によるものだが、同時に、倫理的にもこの一線を越えてはならないという不文律のようなものがあった。Mozillaなど複数のWebブラウザに存在したバグを使って、「アドネットワークを使わずに、あらゆるサイトの履歴を取得する」とうたった「楽天ad4u」というサービスが登場した際には、当の広告業界からも「行動ターゲティング広告ではなく、行動スキミング広告である」として、反対の声が上がったこともある。
だがミログのやったことは、まさに「自社の広告の貼ってあるサイト以外の履歴まで取ってしまうこと」に相当すると高木氏はいう。
収集する情報と目的は一致しているか?
もう1つ論点になりそうなのは、収集される情報の内容と、収集する目的が合致しているかどうかだ。
例えば、PCにインストールされたアプリケーションやプラグインに関する情報を送信し、共有することで、性能を落としている原因を指摘するようなサービスがあったとする。「この場合、『PCの問題を診断してくれるのだから、関連する情報を持っていくのは当たり前だろう』という具合に、目的と手段が直感的に分かる」(高木氏)。
逆に、動画表示用プラグインをインストールするだけで、PCにインストールされているソフトウェア情報すべてを収集して送信するようなプログラムがあれば、それはスパイウェアの一種であると判定されるはずだ。
ユーザーへの説明責任は果たしているか
最後に、ユーザーに対し「どんな情報を、何のために、誰に対して提供しているのか」が、分かりやすく説明されているかどうかもポイントとなりそうだ。説明責任を果たすとともに、オプトアウトの手段を用意するなどして、ユーザーに選択権を持たせることが必要だろう。
現に、グーグルの「Android マーケット デベロッパー販売/配布契約書」には、以下のような記述がある。
4.3 デベロッパーは、マーケットを使用して対象製品を販売/配布するにあたり、ユーザーのプライバシーおよび法的権利を保護するものとします。ユーザーからデベロッパーにユーザー名、パスワード、またはその他のログイン情報または個人情報が提供される、またはデベロッパーの対象製品によってそのような情報へのアクセスまたは使用が行われる場合、デベロッパーは、情報がデベロッパーの対象製品に提供されることをユーザーに認識させ、当該ユーザーについてプライバシーに関する法的に十分な通知および保護を行わなければなりません。また、デベロッパーの対象製品による当該情報の使用については、ユーザーがデベロッパーに対して許可した、限定された目的のための使用のみが認められます。
(出典:Android マーケット デベロッパー販売/配布契約書)
ユーザーの同意を得られているかどうかは、2011年7月の刑法改正で新設された、いわゆる「ウイルス作成・提供罪」にも関わってくる。
ウイルス作成・提供罪は、「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録」を、「正当な理由がないのに……人の電子計算機における実行の用に供した者」を処罰するというものだ。構成要件は2つある。「意図に反する」形で、「不正な指令」を与えるということだ。
甲南大学法科大学院教授・弁護士の園田寿氏によると、ここでいう「人」とは、「同意のない人」という意味であり、アプリに関する説明が十分かどうかという点に関わってくる。例えばあるサイトにアクセスした際、それと知らせず、自動的に別のサイトに自らのアプリ情報や個体番号などが送信された場合は、「意図に反する動作」に該当するという。「AppLogの説明は、この点でかなり不十分であったのではないかと思う」(園田氏)。
加えて、「別の新たな犯罪の手段となり得る『個体番号』を抜くという点において、『不正な指令』といえるのではないか」(園田氏)。これに基づくと、ウイルス作成・提供罪ないしは供用罪に該当する可能性があるという。
落合洋司弁護士も自身のブログで、AppLogに関して次のように見解を述べている。
客観的に見て、利用者の意図に反する動作をさせるもので、かつ、このような機能は社会的に許容し得るものではない、利用者を欺いて情報を入手する『不正な』行為と評価されて、不正指令電磁的記録作成、供用罪に該当するものと、ほぼ言えるでしょう(http://d.hatena.ne.jp/yjochi/20111010#1318232317)。
なおミログは10月10日、app.tvについて「アカウント登録時にプライバシーポリシーおよび利用規約に明示的に同意を頂いているユーザーに対し、同社のリワード広告システム『AppReward』に利用する目的でアプリケーション情報などを取得送信していた」が、「開発過程の間違いにより、アカウントを登録する前の時点で情報送信が開始される誤動作が生じた」との説明を公表し、app.tvの同意画面に見直しを加えた。
しかし落合弁護士は上記のブログエントリで、10月10日に新たに追加された情報を見ても、「取得する情報に関する内容が簡素で、この程度では、上記のような不正指令電磁的記録性を払しょくするとは考えにくいものがある」と述べている(さらにいうと、高木氏によれば、少なくとも10月7日以前はapp.tvの説明画面には、アプリケーション利用履歴の送信について説明する記述はなかった。そもそも上記の説明が「ウソ」だったことになる)。
Androidに対する信頼を損なわないために
過去のWeb業界の流れを追うかのように、スマートフォンの普及に伴い、広告を埋め込んだAndroidアプリが広がりつつある。これを支援すべく、Admobをはじめ、スマートフォンのアプリ向けにアドネットワーク的な広告配信を行う事業者も登場してきた。
おそらくまっとうな広告業者であれば、「自社のスマートフォン向け広告が貼り付けられたアプリの起動履歴だけを収集しており、決して、それが貼り付けられていない別のアプリの履歴を取ったりはしていないと思う」(高木氏)。
だがもし、端末から情報がなし崩し的に送信されるような事態になれば、社会的な損失が生じるのではないかとの懸念がある。
「広告を出していない、無関係なところの履歴まで取られることが当たり前になってしまうと、『自分がどのような情報に関心を持っているか、ばれてしまうじゃないか』という懸念が高まり、PCやスマホ自体を使うことをためらったり、医療関係などセンシティブなアプリを使わなくなる可能性がある。ひいては電子計算機に対する社会の信頼を損ない、センシティブなサービスが成り立たなくなる恐れがある」(高木氏)。
あるAndroidアプリ開発者も、「こういった事例が生じることで、『Androidアプリは怖い』という認識が広がることが怖い」と述べる。
逆に、ミログが公開したアプリによって今回の議論が巻き起こったことは、コミュニティが健全に機能している証拠とも言える。今後、スマートフォン市場が広がる上でも、どういった情報ならば収集してもよく、どこからはだめなのかについての合意を、ユーザーと開発者の間で作っていくことが必要だろう。
One more thing――端末固定情報の是非
開発者にはもう1つ重要な注意事項がある。スマートフォン向けアプリやサイトで、「契約者固有ID」や「IMEI(International Mobile Equipment Identity)」のような端末固定のID(端末ID)を使わないことだ。iPhoneにおける「UDID」、Androidの「Android ID」もそれに該当する。
いわゆるフィーチャーフォンの世界では長らく、認証の部分などに端末IDが利用されてきた。これは、行動ターゲティング広告や「お1人様1回限り」のサービスを実現したいといった、アプリケーション仕様上の必要に迫られてのことだろう。
それでもこれまでは、基本的に閉じたネットワークの世界での実装だったため、「ガラパゴスゆえの一種の安全性」が保たれていた。「だが、スマートフォンによってその安全性は崩れた」と、HASHコンサルティング代表取締役の徳丸浩氏は述べる。
「スマートフォンでも問題は必ず起こると思っていたが、こんなに早く顕在化するとは思わなかった」(同氏)。
端末IDを使うべきでない2つの理由
ではなぜ、端末固定IDを使うべきではないのか。理由は大きく分けて2つある。
1つめはセキュリティ上の問題だ。他人の端末IDが分かれば、簡単になりすましが可能となり、情報漏えいなどにつながってしまう。
パスワードのような秘密情報であれば、第三者に知られること自体が問題となるが、「端末ID自体は必ずしも秘密情報ではない。半公開情報であり、第三者が知ることができる」(徳丸氏)。特にスマートフォンの場合、フィーチャーフォンより容易になりすましや改ざんが可能で、その結果、端末IDにひも付いた情報が漏えいする恐れがある。
それでも携帯電話網という一種の閉じたネットワークで使い、かつ現場レベルで指摘された各種攻撃方法の回避策をとっている限り、端末IDが改ざんされる可能性は低かった。だが、よりPCに近いスマートフォンの普及によって、その前提は変わった。「端末IDは『固有であること』を想定していたのに、固有でなくなってしまう」(徳丸氏)。
改ざんとまではいかなくとも、ランダムに生成した端末IDを用いて、情報を引き出すことも可能だ。現に2010年6月には、「ICC-ID」という固有の番号を使っていた米AT&TのWebアプリケーションから、iPad購入者10万人以上のメールアドレスが流出するという事件が発生した。
機微な情報が明らかに
もう1つはプライバシーに関連する問題だ。「いわゆる『名寄せ』が簡単にできてしまう」(徳丸氏)。異なるサイトやサービスのアクセス履歴を、端末IDをキーにして抽出すれば、「この人はこの時間にこういったサイトにアクセスしており、こういう志向を持っている」という事実が分かってしまう。
例えば、一見普通のサイトを運営して住所や氏名といった情報を収集しつつ、一方で、アダルトサイトを運営しているような事業者がいたとしよう。アダルトサイト側でユーザー登録などを行わなくとも、両方の情報を端末IDをキーにして組み合わせれば、どのユーザーがアクセスしてきたかが分かってしまう。その情報を架空請求に悪用するなど、犯罪に利用される可能性も否定できない。
そこまでいかなくとも、「『この人はこんな趣味を持っている』といった、『他人に見られたら恥ずかしいな』という情報が見られてしまう恐れがある」(徳丸氏)、「端末IDさえ送れば、その人用の広告が表示される。広告の傾向を見れば、その人が男性か女性か、あるいは育毛剤に関心があるのかないのかといったことまで分かる。これはれっきとしたプライバシー侵害」(高木氏)というわけだ。
端末IDは、現行の個人情報保護法でいう個人情報には該当しないという見解もある。例えば園田氏は、ケースバイケースであると断りながらも、「『端末の固有番号、他に導入済みのすべてのアプリの名前、各アプリを使った時間帯などのデータ』などには原則として個人識別性がないので、『個人情報』に当たらないと思われる」という。端末の固有番号についても、「あくまでもデバイスに関連付けられた番号であって、加入者との対応関係は保障されるものではない」(園田氏)。
しかし逆に、高木氏は一歩踏み出して、さまざまなプライバシー情報とひも付く可能性のある端末IDも個人情報に含める形で法律を見直すべきだという。「サイト横断的に、アプリ横断的に、あるいはサービス横断的に共通であって、しかも長期間にわたって変更されないという特性を持つ番号は、個人識別性のある個人情報としてとらえるべき」(高木氏)。
いずれにせよ、端末IDが現行の個人情報保護法でいう「個人情報」には当たらなくとも、それにひも付くのが「プライバシーに関わる、機微な情報」(徳丸氏)であることに異論はないだろう。嗜好や、あるいはよりセンシティブな病気などの情報は、「人によっては、住所氏名といった情報以上に知られるのは嫌だ、関係のないところに出ていく可能性があるだけでも嫌だ、と思うかもしれない」(徳丸氏)。
新しい時代の「コンセンサス」作りを
ご存じのとおり、PCとインターネットの世界では、10年以上前からこうした端末固定IDの弊害が指摘されてきた。古くはインテルが1999年に投入した「Pentium III」で実装した「プロセッサー・シリアル・ナンバー(PSN)」が、個人の特定につながり、プライバシーを侵害するとして批判を受けている。また、サードパーティCookie(第三者Cookie)による履歴収集が問題視されたこともあった(これはオプトアウトによって拒否することが可能だ)。最近では、さらに別の仕掛けで、ユーザーに気づかれにくく、削除しても復元される「スーパーCookie」の問題が指摘されている。
サイトやアプリで端末IDを使ってしまうと、前述のようにユーザーの追跡が容易になり、プライバシーがあらわになる危険性が生じる。しかもこうした固定情報は、悪意を持った人物による改ざんが可能である一方で、ユーザー自身が変更することは難しい。もし他人にこの情報を握られた場合には、端末ごと乗り換えるくらいしか手立てはないが、一般のユーザーにとってこれは手間のかかる作業だ。しかも現状のアプリケーションの作りを見るに、いつ、どんな形で情報が送信されているかが分かりにくく、ユーザー自身によるコントロールが困難だ。
こういった問題点を踏まえてか、スマートフォンアプリ開発の世界でも、端末IDの利用は推奨されない方向に向かっている。アップルは2011年8月、「iOS 5」ではUDID(Unique Device Identifier)を使った端末識別を禁止する旨を発表した。
つい先日にはNTTドコモが、開発者向けの情報として、スマートフォンにデフォルトで搭載する「メディアプレイヤー」に関連し、動画を再生する際にIMEIを送信するという仕様を発表したが、反響を受けてすぐに仕様を変更している。具体的には、マイクロソフトのDRMシステム「PlayReady」で保護されているコンテンツを再生しようとした際、ライセンスがない場合にのみ、そのつど「ユーザーに許諾を取った上で」、IMEIを送出する仕様にした。
NTTドコモ広報部によると、「iモード端末/スマートフォン端末の進化やサーバ技術の発展により、iモード端末におけるCookieの利用など、PC向け技術が利用しやすくなり、システム構築者の自由度が広がっている状況にある」とした上で、「弊社ならびにコンテンツプロバイダーが入手した情報(IDを含む)に関しては、情報入手者が、法令およびお客さまの許諾を得た範囲で利用されるものと理解」しているという。
端末固定の情報の代わりに何を使えばいいかというと、アプリやサービスごとに異なる固有のキーを発行すればいい。認証やセッション管理を実現したいのであれば、それをCookieに格納すればことは済む。ちなみに徳丸氏によると、携帯向けサイトが急増するずっと以前に、ウィルコム(旧DDIポケット)が提供する「PメールDX」で、名寄せができないようサイトごとに異なるIDを用いる実装がなされていた事実もあるという。
セキュリティおよびプライバシー保護の観点から、収集する情報やその利用目的の明示といった項目も含めた「アプリ作りのガイドライン」や、アプリマーケットごとの「推奨項目」を設ける動きがあってもいいかもしれない。
同時に、特にAndoridアプリの場合、アプリに付与する「権限」を、本当に必要なもののみにとどめることも求められるだろう。「本当に必要なものだけではなく、『将来必要になるかもしれない』『もしかしたら要るかもしれない』というだけの理由で付けてしまっている権限が多い」と徳丸氏。だがユーザーからすれば、「何でこの機能を提供するアプリで、『ほかのアプリの情報を収集する』といった権限が必要なんだ」ということになる。疑いを掛けられないようにするためにも、最小限の権限にとどめるべきという。
PCに近付いたスマートフォンの普及によって、以前にはなかった状況が生まれつつある。ユーザー、開発者、広告配信事業者それぞれに重心は異なるだろうが、この新しい時代の「コンセンサス」を作り上げる作業が求められている。
情報をお寄せください:
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ (2017/7/24)
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に (2017/7/11)
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは (2017/7/10)
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から (2017/7/5)
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃(APT:Advanced Persistent Threat)対策の観点から考える。