Share via

ユーザー プライバシー

  • [アーティクル]

 

Mary Kirtland

Microsoft Corporation

2001 年 2 月 14 日

最後の列では、Web サービス ガイダンス チームの最初のサンプル プロジェクトである Favorites Service のビジョンの定義について説明しました。 私は列間の長い遅延について申し訳ありません。私は厄介な寒さで1ヶ月のより良い部分のために出てきました。 今後数か月間の定期的な週単位の列について、今すぐ順調に進むことを願っています。

要約すると、お気に入りサービスの目的は、ユーザーが使用しているマシンに関係なく、ユーザーがこれらのアプリケーションを通じて自分のお気に入りにアクセスできるように、アプリケーションが安全で安全な中央の場所にエンド ユーザーのお気に入りのリンクを保存する方法を提供することです。 技術的な観点からは、これは実装する非常に簡単なサービスのように思えます。 これは基本的に、単なる特殊なデータ ストアです。

私たちがお気に入りサービスを見始めたのと同じ頃、ユーザーのプライバシーに関するニュース記事、特に第三者がWebページ上の広告を通じて収集できる情報に関するニュース記事が多くありました。 これは、Web サービス モデル全体がサードパーティのサービスを使用する Web ページに基づいており、エンド ユーザーの知識がない可能性が高いと考えています。 プライバシーの問題について心配する必要がありましたか?

ユーザープライバシーの適切な定義がなくても、提案されたお気に入りサービスが疑問に思えるいくつかのシナリオを考え出すことができました。 問題に関する最初の調査に基づいて、お気に入りサービスを段階的に実装し、疑わしいシナリオを後のフェーズに延期することにしました。 この列では、最初の調査で発見した内容、延期した困難な問題、プロジェクトのフェーズ 1 に残っているプライバシーの問題、およびこれらのが設計と実装に与える影響について説明します。

プライバシーの定義

まず、ユーザープライバシーの意味を見てみましょう。 ここでは、ユーザーのプライバシーと Web に焦点を当てます。 Web を使用する場合は常に、使用しているアプリケーション (Web ブラウザーなど) とアプリケーションが接続されている Web サイト (ブラウザーに表示されるページなど) の間で交換される可能性がある 3 種類の情報があります。

  • 作成する 電子メール、休暇の写真、財務記録など、アプリケーションの組み合わせを使用して作成する情報。
  • お客様にサービスを提供するためにアプリケーションによって収集された、お客様の名前、住所、個人的な関心など、お客様に関する情報。
  • サービスを提供するためにアプリケーションによって収集された IP アドレスなど、使用しているマシンやネットワーク接続に関する情報。

ユーザーのプライバシーに関する問題は、この情報の収集、使用、および配布方法です。 オンライン書店から本を購入する場合は、もちろん、書店が注文を完了するために、名前、住所、クレジットカード番号を指定する必要があります。 しかし、この情報が、購入した特定の書籍のレコードと共にデータベースにダンプされた場合はどうでしょうか。 一方で、この情報を使用して、お気に入りの著者による新しい書籍が発行されたときに通知するなど、便利なサービスを提供できます。 一方、個人情報を販売し、不要な迷惑メールが殺到する可能性があります。 使用するアプリケーションを提供する企業がこの情報を公正に使用する構成は何ですか?

残念ながら、この質問には万能の答えはありません。 正しいことを決定するのは難しいです。特に、公共の認識と政府の規制が流動的であるためです (また、法的管轄区域によって異なる場合があります)。 今日の Web サイトの標準的なプラクティスは、収集される情報とその使用方法と配布方法をユーザーに通知するプライバシー ポリシーを投稿することです。 ただし、情報を収集する前に、またはユーザーが Web サイトにアクセスする前に、ユーザーがプライバシー ポリシーを読む必要があるかどうかに関する標準はありません。

Web サービスでは、状況がさらに不確実になります。 エンド ユーザーは、Web サービスが使用されていることを知らない可能性があります。 Web サービスが特定のエンド ユーザーに関連付けることができる情報 (個人を特定できる情報と呼ばれます) を収集する場合、サービス プロバイダーは、収集される情報とその使用方法や配布方法についてどのようにユーザーに通知しますか? Web サービスに個人情報を配布するアプリケーションは、エンド ユーザーにこれを開示する必要がありますか? 従来、企業はビジネス プロセスの特定の側面を外部委託することを明らかにしていません。 たとえば、注文フルフィルメント会社とカスタマー サポートの両方が顧客に関する個人情報にアクセスできるorganization、注文フルフィルメントまたはカスタマー サポートが外部委託されていることを会社が開示しない場合があります。 ただし、ルールはオンラインで異なる場合があります。 時間だけが分かります...

公正な情報の実践

公正な情報慣行は、お客様に情報を提供し、個人情報を管理します。 このような情報は、望ましくない使用、アクセス、配布から保護されるため、お客様は会社の製品を使用する際に自信を持って満足できます。 お気に入りサービスに対するユーザーのプライバシーの意味を理解するための最初のステップは、 Microsoft の公正な情報プラクティスを読み上げていました。 Microsoft のコーポレート プライバシー グループは、公正な情報プラクティスの 5 つの要素を定義しています。

  • 注意。 あなたの会社は、個人情報の収集、使用、および配布に関する明確なポリシーを定義する必要があります。 このポリシーには、データのプライマリとセカンダリの使用、社内の事業部門間でのデータの分散、関連会社および非関連会社とのデータ共有、ビジネス トランザクションをサポートするベンダーとの契約義務が含まれている必要があります。 会社は、ポリシーの変更に関するガイドラインと、変更前に収集されたデータに対する変更の影響を確立する必要があります。 法務アドバイザーと協力して、ポリシーが Web サイトと Web サービスで適用できることを確認する必要があります。 オンラインとオフラインを含む複数の配布チャネルを通じて、顧客とユーザーがポリシーを利用できるようにします。
  • 同意します。 ユーザーがデータ収集、使用、および配布の基本設定を管理するための柔軟でアクセス可能なメカニズムを提供する必要があります。 ユーザーが同意している内容を把握し、ユーザーが設定するのに時間がかかりすぎないように、情報を合理的で意味のあるグループに分類する必要があります。 ユーザー設定の既定値を考慮することが重要です。 ユーザーは、個人情報の特定の使用 (オプトインと呼ばれます) を明示的に有効にするか、明示的に使用を無効にする必要がありますか (オプトアウトと呼ばれます)。
  • アクセス。 ユーザーは、保存した個人情報を表示および/または編集して、最新の状態に保たれ、使用設定を管理できる必要があります。 ユーザーが編集できる情報と表示できる情報を把握する必要があります。 たとえば、ユーザーは一意のユーザー識別子の編集を許可されず、パスワードの編集を許可される場合があります。 理想的には、個人情報を管理するツールは、オンラインユーザーとオフラインユーザーの両方が利用できます。
  • セキュリティ。 ユーザーの個人情報を保護するために、適切なセキュリティ対策を実施する必要があります。 これには、保存されているデータへのアクセスを保護するための認証と承認のメカニズムが含まれます。 また、マシン間の転送中にデータを保護するメカニズムも含まれる場合があります。 セキュリティ対策は、情報の機密性に比例する必要があります。 たとえば、ユーザーの銀行口座や医療記録を使用している場合は、お気に入りの作成者の一覧を使用する場合よりも、セキュリティに関する懸念が高くなります。
  • 強制。 プライバシー ポリシーに従わないと、プライバシー ポリシーを設定しても問題ありません。 会社は、プライバシー ポリシーに準拠するために情報システムを監視するための手順を定義 (および従う) 必要があります。 すべての顧客情報サービスの紛争解決プロセスを定義し、サード パーティの認定組織との安全なハーバー関係を維持します。 適用は、Web サイトまたは Web サービス自体の外部に大きく含まれていますが、適用プロセスをサポートするために保持する必要がある監査情報の種類を検討する必要があります。 たとえば、ユーザーがプライバシー ポリシーを読んだかどうか、ユーザーがユーザー設定をいつどのように変更したかなどを追跡できます。

公正な情報の実践とお気に入り

これは理論上は妥当に思えましたが、これが Web サービスにどのように適用されるか、またはこれらの要素をすべて Web サービスに実装する方法については、まだ完全には明らかではありませんでした。 そこで、私は企業ポリシーグループのメンバーと問題について話し合うのに数時間を費やしました。 お気に入りサービスで有効になる可能性があるシナリオの一覧から始めました (最初のビジョン ステートメントに基づいて)。

  1. ユーザーは、インターネット エクスプローラーのお気に入りなどの一連のメニュー オプションを提供する一部のアドインをインターネット エクスプローラーにインストールします。ただし、お気に入りは実際には coldrooster.com に格納されます。 (最後の列を読んだ場合、コンサルティング会社に関するビジネス シナリオが定義されていることがわかります。この架空のコンサルティング会社の名前は、Microsoft キャンパスの建物にぶら下がっている雄鶏に敬意を表して、コールド ルースター コンサルティングであることが明らかになりました。そのため、coldrooster.com。)
  2. Coldrooster.com は、ユーザーが自分のお気に入りを管理できる Web アプリケーションを提供します。
  3. たとえば、msdn.microsoft.com Web サイトには、ユーザーがクリックしてそのページを coldrooster.com に保存されているユーザーのお気に入りに追加できるボタンが各ページに用意されています。
  4. Msdn.microsoft.com は、ユーザーの代わりに msdn.microsoft.com によって最初に保存されたユーザーのお気に入りを表示する Web ページを提供します。
  5. Msdn.microsoft.com は、ユーザーに代わって msdn.microsoft.com によって最初に保存されたお気に入りをユーザーが管理できるようにする Web アプリケーションを提供します。
  6. Cold Rooster Consulting は、保存されているすべてのお気に入りを定期的に取得し、それらを特定のユーザーにリンクする情報を取り除き、分析のために別のデータベースにダンプします。
  7. Msdn.microsoft.com は、ユーザーに代わってお気に入りを最初に保存した Web サイトに関係なく、ユーザーが保存したすべてのお気に入りを表示する Web ページを提供します。
  8. Msdn.microsoft.com は、ユーザーが自分のすべてのお気に入りを管理できる Web アプリケーションを提供します。
  9. コールド ルースター コンサルティングには、ライセンスを msdn.microsoft.com できる別の Web サービスが用意されています。 このサービスを使用すると、ライセンシーは、"お気に入り" や "このページを保存したユーザーもこれらのページを保存しました" などの情報を取得できますが、msdn.microsoft.com ドメインに対してのみ取得できます。
  10. Cold Rooster Consulting では、シナリオ 9 で説明されている Web サービスが提供されます。ただし、msdn.microsoft.com に返される推奨事項には、他のドメインのお気に入りを含めることができます。

ユーザーのお気に入りを電子メール アドレスや Microsoft Passport 識別子などの個人識別にリンクする必要があるため、すべてのユーザーのお気に入りを任意のアプリケーションと任意のマシンで使用できるようにするには、ユーザーのお気に入りのデータが個人を特定できる情報のカテゴリに確実に含まれています。 お気に入りサービスのこの定義が残っている場合は、ポリシー、手順、コードを組み合わせて公平な情報プラクティスを実装する必要があります。

話し合いの時点では、ユーザーに代わって情報を保存する前にユーザーに通知する必要がある法律はありませんでした。 そのため、coldrooster.com にプライバシー ポリシーを投稿することで 、通知 要素を実装できます。 ユーザーは、ポリシーを読む必要があることをどのように認識しますか? 次の 2 つのオプションが考え出されました。サービスを介してお気に入りを保存する前に、ユーザーが coldrooster.com にサインアップする必要があります。または、クライアント アプリケーションは、コールド ルースター コンサルティングのお気に入りサービスが使用されていることをユーザーに通知し、プライバシー ポリシーへのポインターを指定する必要があります。

セキュリティの観点から見ると、ユーザーのお気に入りは医療記録と同じカテゴリに分類されませんが、ユーザーはアクセスできるユーザーを制御する必要があります。 たとえば、ホーム マシンに保存したお気に入りを見ると、サポートしているスポーツ チーム、読みたい本の種類、聴きたい音楽の種類、銀行口座の場所を確認できます。世界中の誰もがアクセスできる情報ではありません。 また、誰かが私のお気に入りを変更できる場合は、選択したリンクを他のサイトに置き換えたり(機密情報の傍受などの悪質な目的の場合)、お気に入りに新しいリンクを追加したりすることができます。 そのため、ユーザーのお気に入りへのアクセスを確実にセキュリティで保護したいと考えています。 また、ユーザーが読み取りまたは書き込み可能なアプリケーションをお気に入りに指定できるようにしたいと考えています。 たとえば、MSDN に msdn.microsoft.com ドメインのお気に入りを変更させる場合がありますが、MSDN にお気に入りのスポーツ チームのリンクも表示されないようにしたいと考えています。 MSDN がそれらのことを気にする必要がある理由

どのアプリケーションでどのお気に入りを読み書きできるかをユーザーが制御できるようにするには、公正な情報プラクティスの 同意 と アクセス の要素を実装する必要があります。 また、 強制 要素をサポートするために監査コードを実装することもできます。

突然、私たちのシンプルな小さなWebサービスはあまり単純に聞こえません! ユーザーにどのようなレベルの制御を与える必要がありますか? 各ドメインからお気に入りを読み書きできるアプリケーションを正確に指定する必要がありますか? または、構成を簡略化するために、アプリケーションとドメインをゾーンにグループ化する必要がありますか? また、上記のシナリオのうち、既定で有効にする必要があるシナリオはどれですか?

プライバシーの専門家は、シナリオ 1 から 5 について懸念を持っていませんでした。 一般的なプライバシー ポリシーでは、これらのシナリオについて説明します。 ただし、シナリオ 2 では、ユーザーのお気に入りを格納しているアプリケーションに関係なく、coldrooster.com がユーザーのお気に入りをすべて管理できるか、Cold Rooster Consulting のアプリケーションが追加したお気に入りのみを管理できるかを検討する必要があります。 おそらく、慎重に誤りを犯し、Cold Rooster Consulting のアプリケーションは、ユーザーの代わりに保存されているすべてのお気に入りを表示または編集するためにアプリを使用できることを明示的に指定しない限り、それらのアプリを介して追加されたユーザーのお気に入りのみを管理できると言います。

シナリオ 6 でさえ、保存されているユーザーのお気に入りを詳細に分析するために使用できるプライバシー ポリシーが示している限り、それほど問題ではありません。 ここでも、データを分析する前に、データをパーティション分割する必要があるかどうかを検討する必要があります(ドメイン別か、最初にデータを提供したアプリケーション)。 また、多くのユーザーはデータ プロファイルを警戒しているため、分析に使用するプールされたデータに自分のお気に入りを含めなくても済むようにユーザーに提供したい場合があります。

残りのシナリオは、プライバシーの観点からますますサイコロになります。 つまり、実装すべきでないとは言えません。正確でわかりやすいポリシー ステートメントを記述するのが難しく、ユーザーはシナリオに慣れていない可能性があるため、おそらく既定で無効にする必要があります (ユーザーはオプトインする必要があります)。

シナリオ 7 は、最初はかなり無害に聞こえますが、Web サービスの観点から実際に意味するのは、アプリケーションがユーザーのお気に入りのすべてのコピーを Favorites Service から取得できることです。 アプリケーションがデータのコピーを取得すると、必要に応じて任意の操作を実行できます。 このシナリオをサポートする Web サービスを提供する場合は、最小限の条件を満たすプライバシー ポリシーを使用して、Web サービスへのアクセスを既知のクライアントに制限することをお勧めします。

シナリオ 8 はさらに問題です。 アプリケーションでユーザーのお気に入りを変更できたら、アプリケーションがユーザーのリストにランダムなページを追加したり、競合他社のサイトを指すお気に入りを削除したりできないようにするには、何が必要ですか? 言い換えると、Web サービスは、エンド ユーザーに代わってアプリケーションによって行われた有効なサービス要求と、エンド ユーザーが認識しないアプリケーションによって行われたサービス要求をどのように区別できますか? HTTP と XML で動作する使用可能なセキュリティ メカニズムは、この種のクライアント/サーバー/サービス シナリオを直接サポートしていません。カスタム セキュリティ ソリューションを実装する必要があります。 カスタム セキュリティ メカニズムを使用する場合でも、ユーザーがどのアプリケーションでどのお気に入りを編集できるかを指定する方法を提供するために、追加の作業が必要になる可能性があります。

最後に、シナリオ 9 と 10 は、シナリオ 6 よりもオンライン プロファイリングの領域にさらに進みます。 技術的な問題は、既に言及されているものと変わっていませんが、ユーザーの不快感レベルはさらに高くなります。

このシナリオの分析に基づいて、お気に入りサービスの最初の配信に関するビジョンを一歩下がって再考することにしました。 フェーズ 1 の新しいビジョンは、上記のシナリオ 3 から 5 に焦点を当てています。 基本的に、各アプリケーションには、ユーザーのお気に入り用の独自のプライベート ストアがあります。 msdn.microsoft.com に移動してこの列へのリンクを保存すると、そのリンクはユーザー インターフェイスを介してのみ表示または編集 msdn.microsoft.com。

この方法では、いくつかの困難な問題が解消されます。 実際には、ユーザーのお気に入りに関連しているため、ユーザーのプライバシーに関する問題全体が排除されます。 Favorites Service を使用する各アプリケーションには、ユーザーのお気に入りの個別のストアが効果的に用意されているため、お気に入りサービスが認識するグローバル ユーザー識別スキームは必要ありません。 各アプリケーションは、任意の種類の識別子を使用できます。 お気に入りサービスには、これらの識別子を解釈したり、異なるアプリケーションによって格納されている情報を関連付けたりする方法はありません。 データにアクセスできるのは 1 つのアプリケーション (つまり、お気に入りサービスの 1 つのライセンシー) のみであるため、ユーザーがさまざまなシナリオにオプトインまたはオプトアウトする方法を提供することを心配する必要はありません。 ユーザー プライバシーの問題を効果的に呼び出し元のアプリケーションに委任しました。

これは、上記のシナリオの分析で発生した技術的な課題の解決を気にしないというわけではありません。 これらは、お気に入りサービスの将来のフェーズで対処したいと考えています。 少し時間をかけて物事を考え、開発者コミュニティに勧めるのが快適なソリューションを考え出したいと考えています。

それでは、今日問題を解決する必要がある場合はどうでしょうか。 ユーザーとアプリケーションの両方にライセンス メカニズムを実装する方法が見つかりません。 ユーザーは、サービスを使用してアカウントにサインアップする必要があります。 つまり、プライバシー ポリシーの読み取り、アカウントへのサインアップ、ユーザー設定の管理を行うことができる Web サイトがあります。 アプリケーションを開発している企業は、Web サービスを使用するためにライセンスにサインアップする必要もあります。 ライセンス契約では、Web サービスの使用についてライセンスがユーザーに通知する方法を指定する必要があります。 Web サービスのみを適切に使用するようにライセンシーを信頼できるかどうかを判断する必要があります。 その場合は、Web サイトでユーザーの資格情報を収集し、Web サービスに渡すことから抜け出すことができます。 そうでない場合は、ユーザーの資格情報を取得して Web サービスに渡す安全なメカニズムを提供するために、ライセンシーが使用できるコードを提供する必要があります。 どちらにしても、かなりの量の作業が関係します。

残りのプライバシーに関する問題

フェーズ 1 のユーザーのお気に入りに関して、ユーザーのプライバシーについて心配する必要はありませんが、まだ考慮する必要があるプライバシーの問題がいくつかあります。 お気に入りサービスへのアクセスをライセンスすることにしました。 つまり、ライセンシーに関する連絡先情報を維持する必要があります。 その情報は、個人を特定できる情報のカテゴリに分類されます。 そのため、アカウント情報を維持するアプリケーションが直面する標準的なプライバシーの問題があります。

ポリシーとコードの組み合わせを使用して、これらの問題に対処しました。 次の図は、システム アーキテクチャの概要を示しています。

図 1. フェーズ 1 のお気に入りサービス アーキテクチャ

このサービスは階層化されたアーキテクチャで実装され、Web ファームとデータ クラスターの 2 つの物理層にデプロイされます。 ライセンシー アカウント情報は、データ クラスター上のデータベースに格納されます。 Microsoft の Web サービスと、ライセンシーがアカウント情報を管理する Web サイトは、Web ファームに展開されます。 ライセンシー情報には、いくつかの保護レイヤーがあります。

  • コールド ルースター コンサルティングの外部のマシンからデータ クラスターにアクセスできません。
  • Favorites Service はライセンシーの連絡先情報にアクセスする必要がないため、ログオン コンポーネントを使用してライセンシーを認証します。 Logon コンポーネントは、必要な情報のみを取得します。
  • 一方、ライセンス管理 Web サイトでは、ライセンシーの連絡先情報にアクセスする必要があります。 ライセンシーがデータを編集できるようにする方法 Web サイトは、ライセンス コンポーネントを介してすべてのデータ アクセスを実行します。 ライセンス コンポーネントのアクセス制御により、ライセンス管理 Web サイト以外がコンポーネントを呼び出すのを防ぎます。
  • licensee データベースに対するアクセス制御により、ログオン コンポーネントとライセンス コンポーネント以外がデータベースにアクセスできなくなります。
  • 連絡先情報が変更されるたびに、連絡先情報で指定されたアドレスに確認の電子メールが送信されます。

ネット効果: 権限のないユーザーがライセンシーの識別子とパスワードを侵害しない限り、ライセンシーの連絡先情報にアクセスしたり変更したりすることは非常に困難である必要があります。 そのような状況でも、誰かが連絡先情報を変更しようとした場合、現在の連絡先に通知されます。

さらに、当社のウェブサイトにプライバシーポリシーを掲載します。 また、お気に入りサービスを使用するアプリケーションの作成方法に関するドキュメントなど、新しいライセンシーに提供する他のドキュメントと共に、プライバシー ポリシーを提供することもできます。

まとめ

ユーザー プライバシーは、Web サービスの開発者と、それを使用するアプリケーションにとって厄介な問題です。 お気に入りサービスの問題を分析すると、サービスの目的全体が再考されました。 スコープが縮小された場合でも、ユーザー情報が不適切な使用から保護されるように、多数の要件が追加されました。 最も重要な要件は、ライセンスされたアプリケーションへのアクセスを制限する必要性でした。 来週、ライセンスについて詳しく説明します。検討したビジネス モデル、選択したモデル、およびモデルが設計と実装に与える影響です。

Web サービスが個人を特定できる情報を維持する必要がある場合は、サービスのコア機能を実装する以外に多くの作業を行う必要があります。 公正な情報プラクティスの 5 つの要素 (通知、同意、アクセス、セキュリティ、適用) すべてに対処する必要があります。 ユーザーと直接対処する必要があるタイミングと、Web サービスを使用してアプリケーションにプライバシーの問題を延期できるタイミングを判断する必要があります。 これらの問題に関するディスカッションに法律顧問を巻き込んで、ユーザーがどこにいてもユーザープライバシー法に関する最新の状態に保つよう強くお勧めします。 次のリソースは、ユーザーのプライバシーに関する追加情報を提供します。