ウェブのプライバシー

ウェブ上でユーザーが利用できるさまざまなプライバシーやセキュリティ機能について詳しく見ていく前に、いくつかの重要な用語を定義しておきましょう。

セキュリティについて触れずにプライバシーについて語ることは困難です。これらは密接に関連しており、セキュリティが十分に整っていないと、プライバシーを尊重するウェブサイトは作成できません。したがって、ここでは両方を定義します。

• プライバシーとは、ユーザーに自分のデータの収集、保存、使用方法を制御する権利を認め、そのデータを無責任に使用しないことを指します。例えば、収集するデータ、そのデータの共有先、使用方法をユーザーに明確に伝える必要があります。ユーザーには、データ使用に関する利用規約に同意する機会を与え、ユーザーが保存しているすべてのデータにアクセスできる権利、およびユーザーがデータの保存を希望しなくなった場合にデータを削除する権利を与えなければなりません。また、ご自身の利用規約も遵守しなければなりません。ユーザーが同意していない方法でデータが使用または共有されることは、ユーザーの信頼を損なう最大の要因となります。これは倫理的に間違っているだけでなく、法律に違反する可能性があります。現在、世界の多くの地域では、消費者のプライバシー権を保護する法律が制定されています（例えば、 EU の GDPR）。

• セキュリティとは、不正アクセスから私的なデータやシステムを保護する行為です。これには、会社（内部）のデータ、およびユーザーやパートナー（外部）のデータが含まれます。セキュリティが脆弱で、悪意のある第三者がデータを盗むことができる場合、ユーザーからの信頼を得るための堅固なプライバシーポリシーを保有しても意味はありません。

個人情報とは、ユーザーを記述するあらゆる情報を指します。例えば、以下の情報が含まれます。

• 郵便物の宛先、メールアドレス、電話番号、などの連絡先情報
• パスポート番号、銀行口座、クレジットカード、社会保障番号、などの公式の識別情報
• 身長、性別表現、体重、髪の色、年齢などの身体的属性
• 病歴、アレルギー、現在の健康状態などの健康情報
• ユーザー名（個人に結び付けられる場合）
• 趣味、関心、それ以外の個人的な好み
• 指紋や顔認識データなどの生体データ

私的情報とは、ユーザーが公に共有することを望まず、非公開にしておく必要がある情報（つまり、特定の権限を持つユーザーグループのみがアクセスできる情報）のことです。私的情報には、法律により非公開と定められているもの（例えば、医療情報など）もあれば、個人の環境設定により非公開とされているものもあります。

上記の節に続き、個人識別用情報 (PII) とは、特定の人物を追跡・識別するために、その全部または一部を使用できる情報を指します。例えば、サイトがユーザーの氏名と郵便番号のリストをオンラインで漏洩した場合、悪意のある者はこの情報を使用して、ユーザーの住所をほぼ確実に特定することができます。完全な漏洩が起こらなくても、ユーザーが使用しているブラウザー、端末、インストールしている特定のフォントなど、あまり目立たない手段でユーザーを特定することが可能です。

トラッキングとは、多くの異なるウェブサイトにおけるユーザーの行動を記録するプロセスを指します。これは、例えば、さまざまな方法で実行できます。

• 複数のサイトにまたがって、サードパーティのコンテンツを埋め込むことで設定されている複数のサードパーティクッキーを見て、ユーザーに関するさまざまな情報ポイントを探します。
• Referer ヘッダーを見て、ユーザーがどこから移動してきたかを確認します。
• インバウンドリンクの URL に、リンク元のサイト、リンクがどのマーケティングキャンペーンの一部であるか、リンクをクリックしたユーザーのメールアドレスやその他の識別情報などをリンク先に開示する引数を含める（例えば、製品ページにリンクする埋め込み広告やマーケティングメールなど）。このプロセスはリンク装飾と呼ばれ、その結果、リンク URL は https：//example.com/article/？id=62yhgt1a&campaign=902 のようになります。
• リダイレクトトラッキングは、追跡者がユーザーを一時的（かつ知覚できないように）に自社のウェブサイトにリダイレクトし、ファーストパーティストレージを使用してウェブサイト間でそのユーザーを追跡するものです。これにより、追跡者はサードパーティークッキーのブロックを回避することができます。例えば、製品のレビューを読んで購入したい場合、知らず知らずのうちにまずリダイレクトトラッカーにリダイレクトされ、その後小売業者のウェブサイトに移動する可能性があります。これは、トラッカーがファーストパーティとして読み込まれ、ユーザーを小売業者に転送する前に、ファーストパーティクッキーに格納されている識別子に追跡データを関連付けることができるということです。

トラッキングデータは、ユーザーのプロファイルやその関心、環境設定を構築するために使用することができますが、これは通常、さまざまな面で不都合が生じ、迷惑となる可能性があります。例えば、次のような場合です。

• ターゲット広告: ある端末で商品を購入しようとして検索したところ、それ以外のすべての端末で、同じ商品の広告が次々と表示されるという不快な経験をしたことがある方は多いでしょう。
• データの販売または共有: 一部のサードパーティーは、追跡データを収集し、それを販売または共有して、ターゲット広告などのさまざまな目的に利用していることが知られています。これは明らかに非常に非倫理的であり、それで何を行うかによっては違法になる場合もあります。
• データによる偏見: 最悪の場合、データの共有により、ユーザーが不当に不利益を被る可能性があります。例えば、保険会社が、共有に同意していない潜在的な顧客に関するデータポイントを見つけ、それを保険料の引き上げの理由として使用した場合を想像してみてください。

トラッキングととてもよく似たプロセスにフィンガープリンティングがあります。これは、ユーザーを他のユーザーと区別するためのデータポイントを蓄積し、それをもとにユーザーを「識別」する手法です。このデータには、クッキーの内容、使用しているブラウザー、ローカルにインストールされているフォントなど、何らかの情報が含まれます。

最近のブラウザーは、フィンガープリンティングによる攻撃を防ぐため、情報へのアクセスを禁止したり、情報を利用できるようにする必要がある場合は、情報を変化させたり「ノイズ」を挿入したりして、識別目的で使用することを防ぐ措置を講じています。

例えば、ウェブサイトがユーザーのブラウザーに経過時間を問い合わせた場合、その時刻とサーバーが報告した時刻を比較することで、フィンガープリンティングの要素として有用になる可能性があります。このため、ブラウザーは通常、タイマーにわずかなばらつきを付加することで、ユーザーのシステムを特定されにくくしています。

ブラウザーベンダーは、ユーザーのプライバシーを保護する必要性、およびトラッキングやフィンガープリンティングなどがユーザーの操作性に及ぼす悪影響を認識しています。このため、プライバシー保護を強化したり、脅威を軽減したりするさまざまな機能を実装しています。この節では、ブラウザーが自動的に適用するプライバシー保護のさまざまなカテゴリーについて説明します。

トランスポート層セキュリティ (TLS) は、ネットワーク経由の通信中にデータを暗号化することで、セキュリティとプライバシーを提供する、 HTTPS プロトコルの基盤となる技術です。 TLS はプライバシー保護に有効です。サードパーティーが送信データを傍受して、例えばトラッキングなどの悪用を行うことを防止するからです。

すべてのブラウザーは、既定で HTTPS を要求するように移行しています。このプロトコルなしではウェブ上でほとんど何もできないため、これは事実上すでに実現しています。

関連トピックは次のとおりです。

証明書の透明性

証明書を監視・監査するためのオープンスタンダードで、不正な証明書や悪意のある証明書の特定に支援するために使用できる公開ログのデータベースを作成します。

HTTP Strict Transport Security (HSTS)

HSTS は、サイトがクライアントに対してサーバーとの通信に HTTPS のみを使用することを指示することによって、プロトコルのダウングレードやクッキーハイジャック攻撃から自身を保護するためにサーバーから使用されます。

HTTP/2

HTTP/2 は技術的には暗号化を使用する必要はありませんが、ほとんどのブラウザー開発者は、これを HTTPS でのみ対応しているので、その点でセキュリティに関連していると考えることもできます。

いわゆる「強力な」 Web API 機能は、潜在的に機密性の高いデータや操作へのアクセスを提供するため、保護されたコンテキスト、つまり基本 HTTPS でのみ利用可能です。それだけでなく、これらのウェブ機能はユーザー許可システムによって制限されています。ユーザーは、通知の許可、位置情報データへのアクセス、ブラウザーの全画面モードへの切り替え、ウェブカメラからのメディアストリームへのアクセス、ウェブ決済の利用などの機能については、明示的にオプトインする必要があります。

ブラウザーには、ユーザーのプライバシー保護を自動的に強化する、いくつかのトラッキング防止機能が実装されています。これらの機能の多くは、 <iframe> に埋め込まれたサードパーティのサイトが、最上位のドメインに設定されたクッキーにアクセスしたり、トラッキングスクリプトを実行したりする機能をブロックまたは制限したりするものです。

• Set-Cookie ヘッダーの SameSite 属性の既定値が Lax に更新され、追跡や CSRF 攻撃に対する保護が強化されました。詳細については、「SameSite 属性によるサードパーティ Cookie の制御」を参照してください。
• すべてのブラウザーは、既定でサードパーティークッキーをブロックするように設定されています。詳細については、「ブラウザーはサードパーティークッキーをどのように処理するのか」を参照してください。
• ブラウザーは、プライバシーを侵害しない特定の状況でのみ、サードパーティークッキーを許可する技術、または現在サードパーティークッキーを必要とする一般的な使用例を別の方法で実装する技術を実装しています。サードパーティークッキーからの移行およびサードパーティークッキーの置き換えを参照してください。
• Firefox、Safari、Brave などの一部のブラウザーは、URL から既知の追跡用引数を削除します。 ClearURLs などのブラウザー拡張機能も、この作業に役立ちます。
• ブラウザーは、リダイレクトの追跡保護を実装しています。

ウェブ開発者がユーザーのプライバシーを改善するために実行できる、また実行すべきアクションはいくつかあります。この節では、最も重要なものについて説明します。カテゴリーの中には、純粋に技術的な課題ではなく、他のチームメンバーとの協力が必要なものもあります。

企業は、さまざまな理由でユーザーからさまざまなデータを収集しています。

• 認証のためのユーザー名、パスワード、メールアドレスなど。
• 連絡用のメールアドレス、郵便物の宛先、電話番号。
• 年齢、性別、地理的な場所、好きな趣味、その他、サイトの個人設定から顧客満足度調査に至るまで、何らかの目的のために使用される PII のホスト。
• 自社サイトおよびそれ以外のサイトにおける閲覧習慣を分析し、ページや機能の成功指標を測定する。
• その他。

顧客からデータを収集する際には、誠実に行動し、信頼性を示し、顧客との良好な関係を構築する機会があります。その結果、ブランドと成功のチャンスを改善することができます。

データ収集の倫理は、3つの単純な原則に分類できます。

• 必要以上にデータを収集しない
• 収集したデータをどのように使用するかを明確に伝える
• 必要がなくなったらデータを削除する

将来有益になるかもしれないと思って、ユーザーに多くのデータを要求したくなるものです。しかし、収集するデータが多ければ多いほど、ユーザーのプライバシーに対するリスクが高まり、ユーザーが実行中の操作（アンケートの記入やサービスへの登録など）を中断する可能性が高まります。

データを匿名化することは良いことです。また、データのリクエストの粒度を細かくし、必要な情報を得られるかどうかを検討することも考えられます。例えば、ユーザーに好きな製品を尋ねる代わりに、より一般的なカテゴリーから選択するよう依頼することができます。

しかし、ユーザーのプライバシーを保護する最善の方法は、収集するデータを最小限に抑えることです。前の例の場合、ユーザーの購買履歴を見れば同じデータを推測することができます。一方、ユーザーは匿名で商品を購入できることを歓迎します。サービスの運営に必要でない限り、ユーザーにアカウントの登録を強制すべきではありません。

収集するデータを決定したら、以下の内容を明記したプライバシーポリシーをサイトに公開すべきです。

• 収集するデータ
• データを使用する方法
• データを共有する可能性がある相手（ある場合）、および共有する前にユーザーの同意を要求する旨の宣言
• データが削除されるまでの保存期間
• 収集したデータをユーザーが確認し、必要に応じて削除する方法

データを提供する場合、そのユーザーには、プライバシーポリシーを読み、それに同意する機会を与える必要があります。ユーザーは、これに同意し、利用規約に同意するかどうかを制御できる必要があります。また、上記で示したように、ユーザーは、自分が収集された自分のデータを確認し、必要に応じて削除できる必要があります。

プライバシーポリシーを公開したら、そのポリシーを遵守する必要があります。ユーザーからの信頼を築くためには、言ったことを実行することがとても重要です。収集すると述べたデータのみ収集し、そのデータを使用すると述べた目的のためにのみ使用してください。社内の誰かが、既存のデータを賢く活用する新しい方法を考え出した場合でも、その目的のために使用することをポリシーで指定していない限り、ポリシーの条件には違反します。ユーザーが特定の目的でのデータの使用に同意し、その目的が拡大した場合、新たな同意を取得することを検討する必要があるかもしれません。

先ほど、ユーザーが自分が収集した自分のデータを確認し、必要に応じて削除できる方法を提供することについて述べました。これは、ユーザーがアカウントを削除する（そのデータも一緒に削除されます）のと同じ操作の一部として実現することも、 2 つの別個のオプションとして実現することもできます。いずれの場合も、オプションは簡単に見つけられる場所に配置する必要があります。

ユーザーが、重要なデータの削除時期を選べるようにすることは、ユーザーに大きな権限を与え、信頼関係を築くことにつながりますが、自分で削除を実行したいデータもあるでしょう。例えば、ユーザーがログインしている間に、そのユーザーのセッションの管理に使用されるデータなど、数時間または数分間しか使用されないデータは、削除したほうがいいでしょう。

先ほど、トラッキングと、その不適切な使用目的について説明しました。このような使用がユーザーの信頼を損なうことは言うまでもありません。可能な限り、サードパーティクッキーなどの潜在的なトラッキングメカニズムは、サイト間のログイン情報やその他の個人設定情報の転送など、倫理的な目的でのみ使用しましょう。

また、前述のように、ブラウザーはすべて、一般的な使用例を実現するための代替技術を実装しつつ、既定でサードパーティクッキーをブロックし始めています。このことに備えて、依存する追跡活動の量を制限したり、他の方法で必要な情報の永続性を実装したりしておくことがよい考えです。詳細については、「サードパーティクッキーからの移行」を参照してください。

もちろん、自分が作成したリソース（コード、Cookie、サイトなど）のみについて心配であれば、プライバシーの管理は簡単です。しかし、実際の課題は、サイトがサードパーティのリソースを使用している可能性が高いことです。これには、<iframe> に埋め込まれたサードパーティのコンテンツ、ライブラリー、フレームワーク、API、画像や動画などの外部ホストのリソースなどが含まれます。

サードパーティーのリソースは、現行のウェブ開発に欠かせない要素であり、多くの機能を提供しています。しかし、サイトに許可したサードパーティーのリソースは、すべて、ご自身のリソースと同じ権限を持つ可能性があります。その権限は、サイトへの記載方法によって異なります。

• <iframe> によってサイトに埋め込まれたサードパーティのコンテンツ内で実行される JavaScript は、同じオリジンポリシーによって分離されます。つまり、最上位の閲覧コンテキストに含まれる他のスクリプトやデータにはアクセスできません。
• ただし、 <script> 要素を介してページに直接含まれているサードパーティのスクリプトは、それが自分のサイトまたは別のサイトでホストされているかどうかに関係なく、他のスクリプトやデータにアクセスすることができます。これは事実上、ファーストパーティのコードとなります。この方法で含まれている悪意のあるスクリプトは、ユーザーのデータを密かに盗み出し、例えばサードパーティのサーバーに送信するなどの悪用が可能です。

サイトで使用しているすべてのサードパーティのリソースを監査することが重要です。それらが収集するデータ、リクエストの内容と送信先、およびプライバシーポリシーを必ず確認してください。慎重に設計したプライバシーポリシーも、それを違反するサードパーティのスクリプトを使用している場合は無意味になります。

サードパーティのリソースを監査し、その動作を理解したら、その価値と引き換えに、そのマイナス面も考慮する必要があります。サードパーティのスクリプトが無料で実に便利であるものの、かなりの量のユーザーデータを収集する場合は、次のようにすることができます。

1. そのトレードオフを受け入れ、その詳細をプライバシーポリシーに更新し、ユーザーの信頼にあまり影響がないことを期待する。
2. データ消費量の少ない、代替のサードパーティー製ツールを探す。
3. 自分自身でツールを構築する。

次のリストは、サードパーティーのリソースを使用する際に固有のプライバシーリスクを軽減するためのヒントをいくつか提供しています。

• サードパーティーのリソースを埋め込む場合は、プライバシーへの影響を少なくして、同じまたは同様の効果を得る方法があるかどうかを検討してください。例えば、ソーシャルメディアの投稿ビューアーをサイトに埋め込むことは楽しいかもしれませんが、それは本当に必要でしょうか？ソーシャルメディアのページへのリンクで十分ではないでしょうか？また、一部のサードパーティーのサービスワーカースクリプトには、プライバシーを強化するオプションがあります。例えば、YouTube の 動画と再生リストを埋め込む > プライバシー強化モードを有効にする を参照して下さい。

• 可能であれば、サードパーティへのリクエスト時に、サードパーティが Referer ヘッダーを受信できないようにブロックする必要があります。これは、例えば、外部リンクに rel="noreferrer" を記載するなど、かなりきめ細かく設定することができます。あるいは、 Referrer-Policy ヘッダーを使用するなどして、ページやサイト全体に対してよりグローバルに設定することもできます。

  メモ: Referer ヘッダーのプライバシーとセキュリティの考慮事項も参照してください。

• HTTP の Permissions-Policy ヘッダーを使用して、API の「強力な機能」（通知、位置情報データ、ウェブカメラからのメディアストリームへのアクセスなど）へのアクセスを制御します。これにより、サードパーティのサイトがこれらの機能を使用して予期しない動作を行うことを防止でき、また、ユーザーは理解できない許可の要求が不要に何度も表示されることを回避できます。 <iframe> 要素内に埋め込まれたサードパーティのサイト内の「強力な機能」の使用も、 <iframe> 自体にある allow 属性内に権限ポリシーを指定することで制御できます。

  メモ: 詳細および例については、権利ポリシーガイド、およびポリシー生成ツールなどの有益なツールが掲載されている permissionspolicy.com をご覧ください。

• <iframe> の sandbox 属性を指定すると、 <iframe> に埋め込まれたコンテンツ内で特定の機能（ダウンロード、フォームの送信、モーダル、スクリプトなど）の使用を許可または禁止することができます。

ユーザーデータを収集したら、そのデータが安全に送信され、格納されるようにする必要があります。これはセキュリティに関するトピックですが、ここで触れておく価値があります。セキュリティが甘く、攻撃者がデータを盗むことができるようでは、良いプライバシーポリシーも意味がありません。

ユーザーのデータを保護するためのヒントを以下に紹介します。

• セキュリティは、適切に実現するのが難しいものです。データの収集を伴う安全なソリューションを実装する場合、特にログインの資格情報などの機密データの場合は、評判の良いプロバイダーが提供する信頼性の高いソリューションを使用することが賢明です。例えば、評判の良いサーバーサイドフレームワークには、一般的な脆弱性から保護するための機能が組み込まれています。また、目的のために専用の製品、例えば ID プロバイダーソリューションや安全なオンラインアンケートプロバイダーなどの使用も検討することができます。
• ユーザーデータを収集するための独自のソリューションを展開する場合は、その内容を十分に理解しておいてください。経験豊富なサーバーサイド開発者やセキュリティエンジニアを雇ってシステムを実装し、徹底的な検査を行って、問題がないことを確認してください。多要素認証 (MFA) を使用して、保護を強化してください。ウェブ認証や連合資格情報管理などの専用 API を使用して、アプリのクライアント側を効率化することを検討してください。
• ユーザーの登録情報を収集する場合は、ユーザーのアカウントの詳細が簡単に推測できないように、強力なパスワードを強制してください。脆弱なパスワードは、セキュリティ侵害の主な原因のひとつです。ユーザーに、複雑なパスワードを生成して格納するためのパスワードマネージャーの使用を勧めてください。そうすれば、ユーザーはパスワードを覚えておく必要がなく、パスワードを書き留めてセキュリティリスクを生むこともありません。
• URL に機密データを含めないでください。第三者が URL を傍受した場合（例えば、 Referer ヘッダーを介して）、その情報が盗まれるおそれがあります。これを避けるため、 GET リクエストではなく POST リクエストを使用してください。
• コンテンツセキュリティポリシーや権限ポリシーなどのツールを使用して、サイト上で機能の使用を制限し、脆弱性の導入を困難にすることを検討してください。この操作を行う場合は注意が必要です。サードパーティのスクリプトが機能するために必要な機能の使用をブロックすると、サイトの機能が損なわれる可能性があります。これは、サードパーティのリソースを監査する際に確認することができます（サードパーティのリソースを慎重に管理するを参照）。

• ウェブセキュリティ
• プライバシーの学習 (web.dev)
• The Privacy Sandbox (privacysandbox.google.com)
• Lean Data Practices (mozilla.org)