「Android Bazaar and Conference 2012 Spring」が、3月24日に東京大学 本郷キャンパスで開催された。同イベントで、産業技術総合研究所情報セキュリティ研究センターの高木浩光氏が「スマホアプリの利用者情報送信における同意確認のあり方」と題した講演を行い、スマートフォンのアプリがどのように情報収集の同意を行うべきかを説明した。

高木浩光氏

3月24日に東京大学 本郷キャンパスで開催された「Android Bazaar and Conference 2012 Spring」において、産業技術総合研究所情報セキュリティ研究センターの高木浩光氏が「スマホアプリの利用者情報送信における同意確認のあり方」と題した講演を行い、スマートフォンのアプリがどのように情報収集の同意を行うべきかを説明した。

オプトインとオプトアウトの線引き

今回の講演は、3月8日に総務省で開催された「スマートフォンを経由した利用者情報の取扱いに関するワーキンググループ(WG)」の第3回におけるヒアリングを拡大したもの。高木氏はまず、講演の前提として、2009年から開催された「ライフログ活用サービスWG」の第2次提言(10年5月)が、行動ターゲティング広告に関して業界のガイドライン策定を促していた点を説明。こうした取り組みに対して、昨年来、「カレログやミログのAppLogがスパイウェアにあたるのでは、と社会的に問題とされた」(高木氏)ことから、今回のWGが開催されることになったと話す。

この中で、参加した事業者から利用者情報を取得する際に「何でもオプトインが必要とされるのはおかしい」「端末IDは必要があって使っている」という訴えがあり、高木氏はヒアリングで「それを踏まえた落としどころは何か、それを提案した」と述べた。

端末IDは、IMEIやUDID、MACアドレスといった、いわゆる「固有ID」のことで、WGで説明した事業者は「携帯会社から送信される携帯端末固有IDをユーザーの入退会管理に利用」しているとの説明で、高木氏は「いかにもガラケー(フィーチャーフォン)でやってきたやり方」と話す。その上で事業者は、アップルなどのメーカーが付与する固有IDも使っていると説明しており、高木氏はメーカーが付与した固有IDを、フィーチャーフォンのやり方と同様に扱うのは問題があると指摘する。

さらに、事業者側からは利用規約にて、こうした固有IDの取得を説明しており、プライバシーマークも取得しているので問題がないという主張だったが、高木氏はこれも問題視する。

別の事業者は、「アカウント認証のためにスマートフォンでも固有IDを利用することがある」と主張していたが、これは「本当にやっていたら脆弱性」と高木氏。こうしたWGに参加しているのは技術者ではないため、説明者が誤解していて、実際には利用していないのかもしれないかもしれない、と高木氏は推測する。

さらに業界団体のモバイルコンテンツフォーラムは、アプリによるユーザー情報取得に対して「全てオプトインとする議論が行われている」と主張しており、高木氏は、「こうした状況は危うい」と懸念する。

ユーザー情報取得に際し、最初に同意を求めるオプトインと、拒否したい人が申請するオプトアウトのどちらを使うべきか、「技術者には何となくのイメージがある」と高木氏。しかし、これを理解しないまま議論を続けていくと、「ビジネスを優先して消費者を省みない、または消費者を優先して技術の進歩を止めてしまう、という二元論になってしまう」(高木氏)。

そのため、高木氏は自分の役割を「(オプトインとオプトアウト)それぞれのケースを検討し、線引きをするのが役目だと思っている」と話す。

分かりやすい同意確認が必要

Androidアプリは、インストール時に権限(パーミッション)を確認することで、アプリが利用する機能をチェックできる。これはJava(J2SE 1.2)で採用されていたモデルだが、普及はしなかった。Androidではこの権限モデルを採用しているが、このモデルでは、例えば位置情報の取得とインターネット経由の情報送信が別々の権限に割り当てられ、「位置情報を取得して送信する」のか、「位置情報を取得するが送信せず、別の情報を送信する」のかの区別ができない。この区別は「技術的に不可能」と高木氏は断じ、このモデルでは権限を確認してアプリをインストールしても、位置情報などの送信に同意したことにはならないと強調する。

今回の問題の背景。Webはセキュリティ制限が厳しく、PCソフトウェアは制限が緩かったが、スマートフォンのアプリはその中間に位置し、機能制限はあるが、従来の携帯アプリよりはできることが多い。ただ、Webのような標準がなく、個々のアプリ提供者の裁量で機能が決まり、新たに問題が起きている、という

権限モデルは以前から使われていたが普及はしなかった。また、明確な同意とは言えない、と高木氏

例えばiOSでは、初めて位置情報を取得する際に同意確認を行い、そうした「OSによる機械式の同意確認」はあってもいいが、それだけでは不十分。アプリ提供者側が個別に同意確認のための仕掛けを行う必要性があると高木氏はいう。あくまでアプリ提供者の自己申告だが、「ウソがあればスパイウェアと言われてしまうので、まじめにやる(申告する)だろう」(高木氏)。

Androidアプリのように、インストール時の権限確認だと、まだアプリを使ってない段階なので、その権限が本当に必要かどうか分からない。例えば「SNSアプリが、付近の投稿を検索するために位置情報を取得する」のであれば、使ってみれば位置情報を取得する理由が分かるので、そこで初めて同意確認をするといったやり方がいい場合もあると高木氏は提案。最初に同意をしないと一切の機能が利用できないというやり方には否定的だ。

そうした同意確認のやり方にはオプトイン、オプトアウト、黙示の同意の3種類があると高木氏は分類。さらにオプトインには強制オプトイン、包括的選択オプトイン、個別的選択オプトインに分類する。強制は、起動時の同意確認で、同意しないとアプリ自体が使えないもの。包括的選択は、起動時の同意確認で、同意しなくてもアプリを利用できるもの。個別的選択は、アプリ利用中に、その権限を使うときに同意確認を求めるもの。これは、例えばFacebookアプリが電話帳のデータから友だちを探す機能で使われているようなものだ。

同意確認のレベル。「仮称」とあるのは高木氏が仮に名付けたもの

Facebookアプリの同意確認の例

オプトアウトは、プライバシーポリシーや利用規約に目的が記載され、その権限の利用を拒否する手段が用意されているもので、黙示の同意は、ポリシーや規約には書かれているが、拒否する手段がないもの、という位置づけだ。