UDIDがはらむプライバシー問題：デジタル・アイデンティティ技術最新動向（6）（2/2 ページ）
前回はUDIDに起因するセキュリティの問題について紹介しました。今回は引き続き、UDIDに起因するプライバシーの問題、特に名寄せの問題について述べていきます。
UDIDとプライバシーの関係について整理する
UDIDと名寄せリスク
UDIDとなりすましの関係については前回の記事でも述べたので、ここではUDIDと名寄せリスクの関係について述べたいと思います。
まず、識別子に求められるプライバシー上の要件についてまとめた、以下の記事をぜひご覧ください。マイナンバー制度にフォーカスした話ですが、ここで議論されている「『利用範囲』と『利用期間』の掛け合わせ」という考え方そのものは、何もマイナンバーに限った話ではありません。UDIDやOAuth、OpenIDにおいてプライバシーの議論をする際にももちろん有効です。
【関連リンク】
マイナンバーとプライバシー：識別子に対する要件
http://www.sakimura.org/2012/08/1796/
マイナンバーとプライバシー：識別子と超過リスク
http://www.sakimura.org/2012/10/1829/
ある識別子の利用期間が長ければ長いほど、その期間内に情報漏えいやログ解析などによって予期せぬ名寄せが行われてしまう危険性は増します。また、利用範囲が広ければ広いほど、名寄せにより情報漏えいが起こり得る個所や取得可能な情報量が増えることになります。これらは自明のことでしょう。
PC Webの世界で行動ターゲティングなどの目的で利用されている識別子、「3rd party cookie」の場合、広告事業者ごとに別個のcookieが発行されるため、そのままでは事業者をまたいだ名寄せはできません（実際には「cookie sync」という手法によって、3rd party cookieを利用しつつ複数の事業者をまたいだ名寄せを行う手法もありますが……）。また、ユーザーが自身のブラウザからcookieを削除することで、それまでのトラッキング結果を無効化することもできます。
一方UDIDは、広く複数のサービスに共有されます。また、ユーザーの意思で識別子を変更することは、Jailbreakなどを行わない限り不可能であり、端末を買い替えるまで識別子は不変であると考えられます。そのためUDIDは、3rd party cookieと比べ、より広範囲に、また（多くの場合）より長期間に渡って利用されることとなり、その分「超過リスク」が存在するといえるでしょう。
なお、AppleはiOS6で、UDIDの代替として「advertisingIdentifier」という識別子を実装しました。これには
- 結局、「どの事業者にも同じ値が返される」という点は変わらない
- 現実的には、ユーザーの意思で値をリセットすることが不可能（端末をリセットする必要がある）
- オプトアウトしても識別子へのアクセスが不可能になるわけではない
などの問題点はありますが、「広告事業者が利用する識別子」と「アプリ提供事業者が利用する識別子」とを分けることで、名寄せされる情報の種類を限定する効果はあるため、UDIDと比べれば名寄せリスクは軽減されています。
UDIDとプライバシー保護の原則
アプリ開発者の間に流れる都市伝説（？）の1つとして、「利用規約に『UDIDを取得する』旨を明記すれば、Appleの審査を通過できる」といった話を聞くことがあります。しかし、利用規約に「端末識別子などの端末情報を取得することがあります」といったあいまいな記述を加えるだけでは、ユーザーがその意味するところを理解できるとは思えません。
特に名寄せリスクは、そのサービス単体で発生するリスクではなく、複数のサービスにまたがってはじめて発生するリスクです。従って、
- その識別子には何がひも付けられていているのか
- UDIDが漏えいした場合、そのサービスからはどのような情報が漏えいし得るのか
- 他のサービスから漏えいし得る情報とひも付けた場合、どこまで個人の特定が可能な状態なのか
といった情報を、各アプリがそれぞれ利用規約に明記し、ユーザーに伝えることは、現実的にはほぼ不可能ではないでしょうか。
またその他にも、
- 事業者が結託して裏で名寄せを行っているのではないかと懸念される状況がある
- オプトアウトが本当に機能しているのかが分かりにくい
といった透明性の不足なども、プライバシー保護の原則に反しています。ここまで、プライバシーの観点からUDIDの抱える問題点を指摘してきましたが、前回の記事で述べた通り、これに加えてセキュリティ面でも問題があることを忘れないでください。
ひるがえって世界の潮流を見てみましょう。最近では米国の「消費者プライバシー権利章典」やEUの「EUデータ保護規則」など、各国ともプライバシー保護を重視する方向に動いています。
【関連リンク】
米国「消費者プライバシー権利章典（Consumer Privacy Bill of Rights）」
http://www.whitehouse.gov/sites/default/files/privacy-final.pdf
EU「データ保護規則（General Data Protection Regulation）」
http://ec.europa.eu/justice/data-protection/document/review2012/com_2012_11_en.pdf
日本ではまだそのような動きは目立っていませんが、国境を越えてサービスを提供する際には当然、米国やEUが定めたルールの影響を受けます。従って、UDIDの抱えるこのような問題を抱えたまま事業を継続するのは、事業リスクとしてもとらえるべきなのではないでしょうか。
「あやしいサービス」の見分け方
ここまで、UDIDの持つプライバシー上の問題点について述べてきました。
現実問題として、プライバシーリスクを抱えたアプリは多数存在しており、ユーザーが安心していろいろなアプリを利用できるような状態にはなっているとは言い難い状況です。そこで最後に、1ユーザーの目からUDID問題を抱えたアプリを見分ける方法を簡単にご紹介します。
1つは、前回紹介した「Charles Proxy」を使う方法です。そうすれば、アプリからそのサーバサイドに送信されるデータをのぞき、通信内容を確認することができます。
一般に「かんたんログイン」のためにUDIDを使っている場合は、アプリ起動時にその識別子をサーバサイドに送信します。そのため、起動時のタイミングで送信されるHTTPリクエストを監視して、ユーザー識別子のような文字列を見ることで、そのアプリがUDIDを使っているのかどうかを判別できます。
仮にアプリを再インストールしても該当の識別子らしき文字列が同一の場合、そのアプリはUDIDを使っている可能性が高いと判断できるでしょう（現実にはkeychainにUUIDを入れている可能性もあります。keychainを使っている場合は、iPhoneをパスワードなしでバックアップから復元すれば、その値は変わります）。
その他に、最近ではアプリの初回起動時に一瞬Safariを立ち上げて、UDIDとSafari上でのトラッキング用cookieをひも付けるといった手法も見受けられます。これは、Safariでブラウジングした際に収集した行動履歴をアプリ内で表示する広告の最適化に利用したり、その逆を行うために行われているようです。
こういった挙動は、基本的にはAppleの審査でrejectされるようですが、中には、審査時のみそういった挙動をオフにして審査をすり抜けてしまうアプリも存在しているのが現状のようです。もしそうしたアプリを見つけたら、発見次第Appleに報告するなど、草の根的な活動によって対策を行っていく必要があるかもしれません。
ユーザーに信頼されるアプリ開発者として
今回は名寄せリスクをメインとして、プライバシーの問題について見てきました。この名寄せリスクを減少するためにも、「意味ある同意」を取れるよう、ユーザーが予想できる範囲内でサービスを運営することが重要です。
もちろんサービス開発者としては、ユーザーをだますつもりはないのでしょうが、もし多くのユーザーからネガティブなフィードバックを受けた際などには、「意味ある同意」をはじめとしたプライバシー原則に基づいて、サービス設計を見直してみていただければと思います。
また、「超過リスク」の考え方などは、自分が携わっているサービスがどの程度のリスクを持っているのか、実際にリスクがある場合にはどのようにしてそのリスクを軽減させていくべきか、考える材料にしていただければ幸いです。
次回は再びOpenIDに関わる話題に戻ります。OpenID FoundationでGoogleが中心となって進めている、UX改善プロジェクト「Account Chooser」について紹介します。
著者プロフィール
Nov Matake
OpenID Foundation Japan Evangelist。個人では、OAuth.jpというサイトを通じて日本語でのOAuthに関する情報発信などを行ったり、OpenID ConnectやOAuth 2.0のRubyライブラリを開発している。
Copyright © ITmedia, Inc. All Rights Reserved.