スマホアプリの利用者情報送信における同意確認のあり方

産業技術総合研究所 情報セキュリティ研究センター

高木 浩光

Android Bazaar and Conference 2012 Spring2012年3月24日（後日配布版）

1

この講演は•3月8日の総務省ヒアリング（15分）の拡大版•「スマートフォンを経由した利用者情報の取扱いに関する

WG」第3回 （「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」のWG）•http://www.soumu.go.jp/menu_sosiki/kenkyu/11454.html•関連：「ライフログ活用サービスWG」2009年•「第二次提言」が2010年5月に出ている•行動ターゲティング広告の業界ガイドラインを促す内容•WGでは事業者からの意見も•何でもオプトインはおかしいという意見•端末IDは必要があって使っているという意見➡ これらに対する落とし所を提案

2

事業者側主張の例•ナビタイム社提出資料より（WG第2回）

3

事業者側主張の例•ナビタイム社提出資料より（WG第2回）

4

事業者側主張の例•ナビタイム社提出資料より（WG第2回）•規約に書いてあれば同意？

5

事業者側主張の例•DeNA社提出資料より（WG第2回）

6

事業者側主張の例•DeNA社提出資料より（WG第2回）

7

事業者側主張の例•DeNA社提出資料より（WG第2回）

8

事業者側主張の例•モバイルコンテンツフォーラム提出資料より（WG第2回）

9

私からの意見の要点•オプトアウト方式で許されるのは限定的なケース•Webのアドネットワークの特殊性に依拠•端末IDは不必要又は有害でありそもそも使わないべき•しかもガラケーの契約者IDとは異なる•Permission機構では同意にならない•あれで同意を得たと言う事業者もいるので•オプトイン方式にもいろいろある•包括的選択と、個別的選択など

10

背景：ウェブからスマホアプリへ •ウェブ•セキュリティ制約による厳しい機能制限• どのサイトを不意に訪れても問題が生じないよう機能を制限• 収集できるのは利用者が自発的に入力した情報に限られる（同意確認不要）• 端末ID的な機能（super cookie）は徹底排除されている• 位置情報の使用はサイト単位でオプトイン方式（ブラウザの機能2009年～）•少数のブラウザベンダにより事実上の標準が確立していた• 結果としてコンテンツプロバイダはその上で可能なことは何でも無断でやってよい•しかし利便性に限界（例：Java Appletは衰退）

•スマホアプリ•中間的な緩さの機能制限• 一般のPCのプログラムのようには自由でない（マルウェア蔓延の防止）• 例：他のアプリのデータを参照することはできないが、アドレス帳は読める等• 「iアプリ」よりは制限が緩い• 例：任意のサイトと通信できる、同意確認なしにアドレス帳を読める等•個々のアプリ提供者の裁量 → 新しい問題が発生

11

Permission確認方式の限界•PermissionはJavaの基本機能（J2SE 1.2 1998年～）•ウェブ用Appletでpermissionを利用者が確認するという方式が採用

されることはなかった•WindowsのActiveXコントロールで一時期近い方式はあったが廃止になった（利用者に見せても判断できずナンセンス）【次ページ】•Androidがそれを採用•ウェブと異なりインストールを要することから利用者に責任を転嫁•使用と送信の許可が独立•例：位置情報を使用することと、何かを外部に送信することは別々

のpermissionで制御される

•「送信しない使用」と「送信する使用」を区別できない•これを区別して許可するpermissionモデルは技術的に実現不可能•各情報の送信に同意したことにはならない•各情報の使用への同意と、何らかの情報の送受信に同意したにすぎない

12

過去の例•ActiveXによるPermissionの確認（2000年）•Visual J++ によるもの

13

つまり•機械式の同意確認には無理がある•うまくいくのはごく一部のケース•OSによる機械式の同意確認は補助的なもの•アプリ提供者による同意確認のための仕掛けが必要•アプリ提供者の自己申告で•自然言語による説明で•個別のプログラムによる同意確認処理で

14

検討の例•位置情報を一部の機能でのみ使うアプリの場合•iOSでは、アプリ初回起動時に許可するか選択•OSレベルで機械的に•しかし、これから使おうという段階で、そのアプリがどんな

必要性があって位置情報を使うのか、利用者にはわからない

•本来は位置情報を使おうとした時点で同意を求めるのがよい•同意しないと一切使わせないアプリ•初回起動時に利用規約を表示して同意を求め、「同意しない」を選ぶと終了するアプリ

15

同意確認のレベル•オプトイン方式（細目に分けるべき）•強制オプトイン（仮称）•同意しなければ一切の利用ができない• 利用者は理解が足りないまま同意ボタンを押しがち•包括的選択オプトイン（仮称）•アプリ全体に対して起動時に同意を求め、拒否しても利用ができる• 利用者は理解が足りないまま同意ボタンを押しがち•個別的選択オプトイン（仮称）•アプリ使用中に当該機能を使用する段になって同意を求める• 利用者は状況の流れから何が起きるか理解しやすい【次ページ】

•オプトアウト方式（Do Not Track対応を含む）•ポリシーや規約に書かれ、拒絶手段が用意される

•黙示の同意（仮称）•ポリシーや規約に書かれているだけで、拒絶手段なし

16

facebookアプリの例•友達を探す機能での電話帳の利用

17

基本的な考え方•利用者の意図に反した動作とならないようにする•不正指令電磁的記録に関する罪（刑法168条の2 ）との関係

•個人情報保護法17条 偽りその他不正な手段によらない取得

•当該機能の存在を利用者が予見できるか

•歴史的経緯（国際的な）を踏まえる•意図に反するか否かは、社会通念に照らしその機能につき一般に認

識すべきと考えられるところを基準とする

•サービス実現のための技術的必然性があるか•利用者が期待するところのサービスの実現にとって

•必要最小限の技術手段を用いるべき

•取得情報の範囲が利用者の想定し得る範囲内か

•情報元の種類による個別の判断18

分かり易い説明が必要•わからない例

19

IDの匿名性レベル•アプリ間で共通で使用されるID（グローバルID）• IMEI、UDID、MACアドレス、Android ID等、及びそれから変換され

た値（ハッシュ値等）

•提供先や流出先で個人が特定され得る• 個人情報保護法23条（第三者提供の制限）の趣旨に触れる• 個人情報保護法20条（安全管理措置義務）の趣旨に触れる•「個人情報」に該当するかは別として（「第二次提言」参照）•「匿名の」IDというべきではない【次ページ】

•第三者cookie（スマホアプリでは現状使用できない）•提供先や流出先で個人が特定されない

•第三者cookie発行元サイトでのみ個人と突合できる

•ある種の匿名ID（個人情報保護法23条、20条の趣旨に触れない?）

•アプリにローカルなID（第一者cookie相当）•提供先や流出先で個人が特定されない

20

米国では•米国消費者プライバシー権利章典•ネットワーク社会における消費者データプライバシー」という

行政白書に大統領が書名（2012年2月）

•以下の記述がある•The Consumer Privacy Bill of Rights applies to commercial uses of personal data. This term refers to any data, including aggregations of data, which is linkable to a specific individual. Personal data may include data that is linked to a specific computer or other device. For example, an identifier on a smartphone or family computer that is used to build a usage profile is personal data. This definition provides the flexibility that is necessary to capture the many kinds of data about consumers that commercial entities collect, use, and disclose.

21

オプトインを必要としないケース•黙示の同意がある•利用者の自発的な入力情報送信はそれ自体が同意によるもの•パスワード入力を伴うログイン時のユーザIDの入力を含む

•自発的な発声、カメラ撮影、ファイルアップロード等を含む•目的外使用しない前提で•ウェブのブラウザが自動送信するのと等価な情報の自動送信• IPアドレス、ブラウザ名（UserAgent）、OSバージョン、URL等•アプリにローカルなID（第一者cookie相当）の使用

•サービス実現（利用者が期待する）のために技術的必然性のある処理により結果的に生ずる情報取得•目的外使用しない前提で

•オプトアウトで許容される•第三者cookieのIDを用いたアドネットワークによる履歴収集•当該アドネットワーク配備サイト上の履歴に限る

22

オプトアウト方式•原則的には望ましくない•オプトアウト手段の存在を知らない利用者の存在• オプトインを嫌がる理由が事業者にないならばオプトイン方式にすればよい• スマホのアプリの場合は利用者はインストールという手順を踏むのだから、そこでオプト

インの手順が入っても事業者側は困ることではないはず•不完全なオプトアウト手段しか提供できない現状• フラグcookieによるオプトアウトはオプトアウト設定が消えてしまう• 複数のサービスに対してオプトアウトして廻る必要があり現実的でない• これらはDo Not Trackで解決される

•オプトイン方式が現実的でなく有用性が勝る場合•例• コンテンツ上の広告• ただし第三者cookieによるトラッキングに限る（グローバルIDを用いたものはオプトアウ

ト方式では許容されない）• Wi-FiアクセスポイントのMACアドレスを用いた位置測位システム（MACアドレスを傍受される側の同意）• Google Street Viewの無差別撮影写真掲載

23

基準適用例（未完）•アドレス帳の使用•個別的選択オプトインが望ましい（Facebook等の例）

•アプリによっては強制オプトインや黙示の同意でよい場合も• 例えば、アドレス帳編集機能が主体のアプリの場合

•詳細な位置情報の使用•ウェブブラウザでは個別的選択オプトインになっている• 位置情報を必要とした時点でサイト単位での同意確認が出る• iOSではアプリ単位で包括的選択オプトインになっている

•アプリ内容によっては個別的選択オプトインが望ましいのでは

•（コンテンツ内）アクセス（利用状況）解析•第一者cookie（ローカルID）使用の場合は黙示の同意でよい• ただし、コンテンツ内操作履歴については分野ごとのコンセンサスが必要•第三者cookie使用の場合はオプトアウト方式が必要

•グローバルID使用は基本的に許されない（技術的に不必要）24

基準適用例（未完）•他のIDとの連携•個別的選択オプトイン（連携を許可するボタン）•例：spモードにおけるOpenIDを用いたPPIDの払出し場面•登録済みの住所氏名カード番号等•個別的選択オプトイン•アドネットワーク外を含む閲覧利用履歴•個別的選択オプトイン•例：GoogleツールバーのPageRank表示機能オプションの利用

25

端末IDは使用しない•そもそも不必要•アプリにローカルなIDを使用すれば済む場合が多い•開発技術者の不勉強によるもの【次ページ】•複数アカウント登録防止用としても有効に機能しない•端末IDの偽装（すり替え）を防ぐことは原理的に不可能•スマホではガラケーと異なりキャリアのゲートウェイを通らないため•なりすましを許すセキュリティ脆弱性となる•端末IDで利用者識別をしている場合、他人の端末IDの送信で、その

人になりすまして操作できてしまう欠陥となる•個人情報（履歴等のプライバシー情報）の漏洩、不正操作等の被害• 他人に自分向けの行動ターゲティング広告を見られる被害•一般のPCでは使用してこなかった歴史•米国でも端末IDの使用は非難の対象

26

まだの方はこちらを

27

行動ターゲティング広告の脆弱性•端末IDを用いた行動ターゲティングはやっちゃ駄目•他人の端末IDを送信すればその人向けの広告を盗み見れる•「ああ、あの人、こういうのが好きなんだ」•例【次ページ】、実証実験【次々ページ】•原理的に避けられない•端末IDをハッシュ値等に変換しても無駄•他の方法•端末内に独自のIDを乱数で記憶させアプリ間で共有する方法•その場合はそもそも端末IDを使う必要がない（使うな）•この案もバッドアイデア•任意のアプリから使えるsuper cookieになってしまう（OpenUDIDの例）•第三者cookieによるアドネットワークはそうはならない•cookieの内容は他のドメイン名サイトに漏れることがないから

28

端末IDによる広告の例•mediba社による説明•MACアドレスを使うそうな（UDIDが禁止されたから？）

29

端末IDによる広告の例•MACアドレス入力によるオプトアウトの例•入力された文字列をそのままSHA1で変換して送信

30

実証実験•AdMobもUDID（のMD5値）を使っている•UDIDを他の端末のものに差し替える実験

31

実験結果•他の端末で同じ属性情報が表示された（協力者による）

32

第三者cookie•第三者cookieによるIDがオプトアウトで許容される理由•提供先や流出先で個人が特定されない•IMEI、UDID等のグローバルIDとは性質が異なる•発行元でのみ個人特定情報との突合が可能だが、それをしない

約束を条件にオプトアウト方式で許容される•米国DoubleClick社集団訴訟の和解条件（2002年）•これは特殊ケース•このケースに引きずられて、他のケースでもオプトアウトで許容せよと主張するのは合理性がない

•なお、スマホでは現時点ではこの機能は実現できない33

議論を要する事項•情報元の種類による個別の判断•例：カメラやマイクその他一部のセンサーの使用•データを加工しプライバシー性を低減して送信する場合であっても、撮

影や録音をすること自体にオプトインを要するのではないか

•分野ごとのコンセンサス形成が必要な領域•例：「電子書籍」と謳われたアプリ•コンテンツ内のページ閲読状況まで記録して送信することは、オプトインを要するのではないか（業界で決める必要があるのでは？）•例：音楽再生•コンテンツの購入履歴がオプトインなく利用されるのは許容されると考えられるが、再生履歴の利用はオプトインを要するのではないか

34

基準の現実性と課題•広告モジュールでの位置情報の使用•広告モジュールにオプトインはあまり現実的でない

•国別の広告を配信するために位置情報を用いる例が散見される• 詳細な位置は不要で、他の手段を用いるべきでは•詳細な位置情報を用いた広告配信は別格でオプトインが妥当

•端末IDなしではアプリ間行動ターゲティングが実現不可•スマホアプリでの第三者cookie機能の欠如• アプリに他のアプリを重ねるインラインフレーム機能をOSが提供する等の解決策•第三者cookieのIDによるアドネットワークと同等にオプトアウト方式で許容

•フィーチャフォン（ガラケー）の契約者ID/端末ID送信•キャリア各社はスマホへ全面移行中と思われる

•経過措置として当面黙認せざるを得ないのが現実• せめて包括同意をとるべきでは？（ソフトバンクモバイルは初回使用時に実施）•キャリアGWで付与するものについてはなりすまし抑制手段あり

35

その他•用語の誤用が散見される•オプトアウト方式においてオプトアウト前の状態を「オプトイ

ン状態」と誤用（アドネットワーク事業者）

•オプトインの取り消しのことを「オプトアウト」と誤用•何をオプトアウトするのか誤った説明•停止するのは広告の配信なのかトラッキング（IDを用いた履歴収集）なのか（米国動向「Do Not Track」との関係）

•利用者に理解されるためにできること•用語の標準化•「オプトイン」は利用者に見せる言葉ではないと思う•オプトアウト手段提供画面の標準化•オプトイン手続きの優れた事例の紹介（表彰等）36

今後•WGは6月に一定の結論を出すとのこと•パブコメ（パブリックコメント）出しましょう！

•妥当な結論への障害となりそうなこと•抵抗勢力事業者が文句を言うかも• 「端末IDを無断で使うの認めろ」とか「技術の進歩を阻害する」とか• 技術者各位におかれましては社内の理解の普及にご尽力を•アプリでの行動ターゲティング広告の実現手段がない• 必要な機能がない旨をOSベンダーに伝える（必要としている人が）

•米国の動向•米下院、個人情報収集についてiOSソーシャルアプリ34社に回答を要

求, Engadget 2012年3月23日（昨日）• 「5.（略）を送信あるいは保存したか。たとえば（略）UDID、MACアドレス、あ

るいはほかすべての端末固有の識別情報など。」

•善良な事業者が「即死」しないために37