モバイル・ユーザのプライバシー権利章典
Last modified: 2012-03-02 00:00
Last modified as a translation into Japanese: 2023-01-03 11:33:25
Translated by Takayuki Kawamoto from https://www.eff.org/deeplinks/2012/03/best-practices-respect-mobile-user-bill-rights, written by Parker Higgins, and this document is distributed under Attribution 3.0 United States (CC BY 3.0), and this translation is also redistributed under the same license.
スマートフォンのアプリケーションは強力なテクノロジーの代表と言ってもよく、それはほんの数年の間に重要なテクノロジーとなってきた。しかしプラットフォームとしてスマートフォンがもっている固有のアドバンテージ、つまり常時接続したまま携行して位置情報や写真あるいは音声といった現実の情報にアクセスするというアドバンテージは、プライバシーを脅威に晒してもいる。そして多くの利用者がスマートフォンに記録しているデータが機微であれば、製造業者、キャリア、アプリケーション開発者、そしてモバイル広告ネットワーク企業はますます重要になってくる公での信頼を獲得して維持するため、ユーザのプライバシーに関しては更に配慮する必要がある。
幸いにも、プライバシーの権利が何であり、ユーザが何を期待しているかを理解するための枠組みは既にある。本稿で以下に述べるベストプラクティスは、EFF によるソーシャルネットワーク・ユーザの権利章典や、ホワイトハウスが最近公開した「ネットワーク世界における消費者データプライバシー」という白書のような文書に基づいており、それらをベースラインとして、モバイル産業のプレイヤーがユーザのプライバシーを尊重するために為すべきことを設定している。
これらのうち幾つかの手法については、モバイル・プラットフォームのプロバイダや広告ネットワークといった他の業種が参加してもらう必要もある。それぞれの業種にはそれぞれの責任があり、アプリケーション開発者はこれらのベストプラクティスについて主要な役割をもっているが、その役割には、為すべきことやっている広告ネットワーク業者を選択するということも含まれるし、あるいはプライバシーを保護するポリシーや手法を組み込んだプラットフォームによって自身の開発をサポートするということも含まれる。
モバイル・ユーザの権利章典
開発者は以下の権利に配慮したアプリケーションを作らなければならない。
- 本人による管理を提供する (Individual control): ユーザには、アプリケーションが自分自身についてどのような個人データを収集し、どのように利用するのかを管理する権利がある。スマートフォンの OS には何らかのアクセス制御のしくみがあるとはいえ、プラットフォームによって技術的あるいは法的に要求されていなくても、開発者はユーザにできるだけ自分自身のデータについて管理する権限を与えるよう努力しなくてはならない。本人による管理の権利には、同意を破棄してアプリケーション・サーバからデータを引き上げる権能も含まれる。ホワイトハウスの白書は、これを適切にこう表現している。「事業者は同意を得る方法で求めるものと同じ資格によって同意を破棄する方法も提供しなければならない。例えば、もし消費者が彼らのコンピュータにおいて一つの行為を通じて同意を与えたならば、彼らは同じやり方で同意を破棄できなくてはならない。」
- データの収集を限定する (Focused data collection): オンラインサービスのプロバイダにとっての標準的なベストプラクティスに加えて、アプリケーション開発者は、モバイル機器に特有の事情について特別な配慮を求められる。アドレス帳の情報や写真のコレクションは、既にそれの内容自体がユーザの過去を物語る重要なプライバシーである。機微の情報は他にも、位置情報データや、通話あるいはテキストメッセージによる通信内容やメタデータがある。モバイルアプリケーションの開発者は、自身のサービスを提供するにあたって必要最低限の情報だけを収集するようにしなければならず、個人情報を匿名化する機能を情報が格納されるまで注視しておかなくてはならない。
- 透明性 (Transparency): ユーザは、アプリケーションがどのデータにアクセスし、そのデータがどのくらい保持され、そして誰がそのデータを共有するのかを知るべきである。また、ユーザはアプリケーションをインストールする前でもインストールした後でも、読めるようになっているプライバシーやセキュリティのポリシーにアクセスできるようになっていなければならない。透明性は、ユーザが直にアプリケーションとやりとりできない場合（例えば Carrier IQ のようなアプリケーションとは直にやりとりできない）に、特に重大な要件である。
- 状況に合わせる (Respect for context): データを収集するアプリケーションは、情報を提供する状況に一致したやりかたでデータを利用したり共有しなければならない。もし「友達を見つける」ために連絡先のデータを収集した場合、そのデータは第三者と共有されるべきではないし、アプリケーションからそれらの連絡先へ直に通信するために使われてはならない。もし開発者がデータを二次利用したいなら、ユーザから明示的にオプトインで許可を得なければならない。
- セキュリティ (Security): 開発者は、収集したり保存する個人データのセキュリティに責任を負っている。つまり、データは可能な限り暗号化されなくてはならず、電話とサーバでデータを転送するときはトランスポート層においてデータが常に暗号化されていなければならない。
- 説明責任 (Accountability): つまるところ、モバイル産業のあらゆる当事者は、自分たちが製造したハードウェアや実装したソフトウェアの挙動について責任を負っている。ユーザは彼らに説明責任を要求しうるのである。
技術上のベストプラクティス
では、どうすればこの権利章典に沿った開発ができるのか？ 次に、開発者がユーザのプライバシーを保護できる幾つかの手法を紹介する。
- 匿名化と難読化 (Anonymizing and obfuscation): 可能ならいつでも、情報はハッシュ化されたり難読化されたり、それ以外の方法で匿名化すべきである。例えば「友達を見つける」機能について言うと、アドレス帳のメールアドレスをハッシュ化してサーバにアップロードしたとしてもメールアドレスが一致するかどうかは確認できる。
- 安全なデータ転送 (Secure data transit): TLS 接続は、あらゆる個人情報 (personally identifiable information) を伝達するための基本であり、機微の情報を伝達する基本にもすべきである。
- 安全なデータストレージ (Secure data storage): 開発者は、サービスを情報の取得から後に [つまりリアルタイムにではなく] 提供する必要がある場合にのみ情報を保持するべきであり、その保持する情報は正しく暗号化されていなくてはならない。
- 内部のセキュリティ (Internal security): 事業者は外部の攻撃者に対抗するセキュリティだけを提供するのではなく、機微の情報を閲覧する権限を悪用する従業員という脅威にも対抗するセキュリティも提供しなくてはならない。
- ペネトレーションテスト (Penetration testing): シュナイアの法則を思い出そう：「無知なアマチュアから最高の暗号学者に至る誰であろうと、自分自身が破れない [というだけで安全だと勘違いしてしまうような] アルゴリズムを作れてしまうものだ。」セキュリティシステムの実装は、どこまでテストや検証した上で妥協するかという問題でしかない。
- トラッキングするな (Do Not Track): ユーザに対してプライバシーに関する選好を効果的に示す一つの方法は、OS レベルで Do Not Track (DNT) の設定を提供することである。現在、DNT は殆どウェブブラウザの機能に限定されていて、Mozilla が開発中の Boot to Gecko という OS だけが OS レベルで Do Not Track フラグをサポートしている。しかし開発者は、プライバシー設定に関する方針を明確に述べるなら今の段階でも多くの人の評価を得るだろうし、他の OS メーカに DNT をサポートするよう働きかけるべきでもある。
これらの推奨事項はベースラインを示しており、アプリケーション開発者から広告ネットワーク事業者あるいはプラットフォームのプロバイダ等々に至る全てのプレイヤーは、連携して課題を乗り越えなくてはならない。モバイルアプリケーションのエコシステムが成熟してくると、ユーザは機微のプライバシーに関するポリシーや取り扱い手法について期待するようになる。今や、彼らの期待に応えるべき時である。