サードパーティ

サードパーティとは

ウェブサイトがすべて自己完結していることはまれです。HTTP ウェブ アルゴリズムによると、ほとんどのウェブサイト（約 95%）にサードパーティのコンテンツが含まれています。

Almanac では、サードパーティのコンテンツとは、共有の一般公開オリジンでホストされているものとして定義しています。このようなコンテンツはさまざまなサイトで広く使用されており、個々のサイト所有者の影響を受けません。画像のほか、動画、フォント、スクリプトなどのメディアを使用できます。イメージとスクリプトでは、すべての要素を組み合わせるよりも多くの要素が考慮されます。サードパーティのコンテンツはサイトの開発に必須でありませんが、必要不可欠な場合もあります。ウェブフォントや、動画の埋め込み iframe、広告、JavaScript ライブラリなど、公開共有サーバーから読み込まれるものを使用することになるでしょう。たとえば、Google Fonts から提供されるウェブフォントを使用している場合や、Google アナリティクスで分析を測定している場合、ソーシャル ネットワークの「いいね！」ボタンや「でログイン」ボタンを追加している場合、地図や動画を埋め込んでいる、サードパーティ サービスを介してショッピング購入を処理している場合、エラーの追跡や自社の開発チームのために、サードパーティのモニタリング ツールを使ってエラーやログを記録している場合があります。

プライバシー上の理由から、やや異なる、あまり広くない定義を考えるとよいでしょう。サードパーティ リソース（特にサードパーティ スクリプト）は、一般公開されている一般公開元から提供され、広く使用されていますが、サイト所有者以外のユーザーによって作成されていることもあります。ユーザーのプライバシーを他のユーザーから保護する方法を検討する際には、第三者の著者情報が重要です。これにより、どのようなリスクが存在するかを検討し、そのリスクに基づいてサードパーティ リソースを使用する方法または使用するかどうかを決定できます。すでに説明したように、これらの機能はコンテキストを理解し、ひいてはどのトレードオフを行うべきか、そしてそれが何を意味するのかを理解するのに役立ちます。

一般的に「サードパーティのリソース」について説明する場合、これはあまり意味がありません。ファースト パーティとサードパーティの区別は、実際には何かが使用されるコンテキストに関するものです。別のウェブサイトから読み込まれるスクリプトはサードパーティのリソースであり、スクリプトを読み込む HTTP リクエストには Cookie が含まれている場合がありますが、それらの Cookie は実際には「サードパーティ Cookie」ではありません。これは単なる Cookie であり、スクリプトがサイト上のページとスクリプト所有者のサイトのページのどちらで読み込まれているかによって、「サードパーティ Cookie」ではありません。

サードパーティのリソースを使用する理由

サードパーティは、サイトに機能を追加するための優れた方法です。たとえば、ユーザーに公開されている機能の場合もあれば、エラー トラッキングのような隠れたデベロッパー機能である場合もあります。こうした機能によって開発の負荷が軽減され、スクリプト自体は別のユーザー（対象サービスの開発チーム）によって管理されます。これらすべてがうまくいくのは、ウェブがコンポーザビリティであるからです。つまり、複数の要素をまとめて、合計よりも大きな合計を形成できることです。

HTTP アーカイブのウェブ アルゴリズムにはわかりやすい説明があります。

サードパーティは、画像、動画、フォント、ツール、ライブラリ、ウィジェット、トラッカー、広告など、Google のウェブページに埋め込むことができるあらゆるもの無限のコレクションを提供しています。これにより、技術者でなくてもコンテンツを作成してウェブに公開できます。サードパーティがいなければ、ウェブは、今日の多くの人々の生活に欠かせない、充実した没入型の複雑なプラットフォームではなく、テキストベースの非常に退屈な学術メディアになる可能性があります。

サードパーティのリソースでできること

一部の情報にアクセスする

ウェブサイトでサードパーティのリソースを使用すると、それが何であるかにかかわらず、一部の情報がそのサードパーティに渡されます。たとえば、別のサイトの画像を含めた場合、ユーザーのブラウザが送信する HTTP リクエストでは、リファラー ヘッダー、ページの URL、ユーザーの IP アドレスが渡されます。

クロスサイト トラッキング

同じ例で言えば、サードパーティのサイトから画像が読み込まれるときに Cookie を含めることができます。ユーザーが次にその画像をリクエストしたときに、その Cookie がサードパーティに返されます。つまり、サードパーティはサイトで自社のサービスが使用されていることを認識でき、そのユーザーの一意の ID を持つ Cookie を返すことができます。つまり、ユーザーが次回サイト、またはそのサードパーティのリソースを含むその他のサイトにアクセスすると、一意の ID Cookie が再度送信されます。これにより、サードパーティは、そのユーザーがアクセスしたサイト、つまり同じサードパーティ リソースを使用する他のサイト（ウェブ上のすべてのサイト）のログを構築できます。

クロスサイト トラッキング: サードパーティは、多くのウェブサイトでのユーザー アクティビティのログを収集できます。ただし、すべてのウェブサイトが同じサードパーティのリソースを使用している場合に限ります。たとえば、フォント、画像、スタイルシートなど、静的リソースです。スクリプト、ソーシャル メディアのボタン、広告などの動的なリソースも利用できます。付属のスクリプトは動的であるため、さらに多くの情報を収集できます。つまり、ユーザーのブラウザと環境を検査して、そのデータを呼び出し元に返します。どのスクリプトでもある程度は可能です。たとえば、ソーシャル メディアの埋め込み、広告、共有ボタンなど、スクリプトとしては存在しない動的リソースも同様です。よく利用されるウェブサイトの Cookie バナーの詳細を調べると、トラッキング Cookie をユーザーに追加している可能性のある組織のリストを確認できます。こうした組織では、ユーザーのアクティビティの全体像を作成してユーザーのプロフィールを作成できます。数百個あります。サードパーティが無料でサービスを提供している場合、そのサードパーティが経済的に実現可能な方法の一つは、そのデータを収集して収益化していることです。

ブラウザがユーザーを保護するプライバシーに関する問題の種類については、Target Privacy Threat Model をご覧ください。 このドキュメントは執筆時点でまだ検討中ですが、存在するプライバシーの脅威を大まかに分類しています。サードパーティのリソースによるリスクには、主にウェブサイトが複数のサイトで同じユーザーを識別できる「望ましくないクロスサイト認識」と、ユーザーが機密情報と見なす情報をサイトが収集する可能性がある「機密情報の開示」があります。

これが重要な違いです。不要なクロスサイト認識は、サードパーティが追加の機密情報を収集していなくても、ユーザーが自分の ID を管理できなくなるため、悪影響を及ぼします。ユーザーのリファラー、IP アドレス、Cookie にアクセスすること自体が望ましくない開示行為です。サードパーティのリソースを使用する場合、プライバシーを保護しながらリソースをどのように使用するかについて、プランニングの要素も伴います。その作業の一部はサイト デベロッパーとして行われることもあれば、ブラウザがユーザー エージェントとしての役割で行われるものもあります。つまり、エージェントがユーザーに代わって作業を行い、機密情報の開示と不要なクロスサイト認識を可能な限り回避します。以下では、ブラウザレベルとサイト開発レベルでのリスク軽減策とアプローチについて詳しく説明します。

サーバーサイドのサードパーティ コード

以前の「サードパーティ」の定義では、HTTP Almanac のクライアント側のアプローチを意図的に変更して（レポートが適切です）、第三者の著者情報を含めています。これは、プライバシーの観点から、サードパーティとは、お客様ではないユーザーについてあらゆることを知っているすべての人であるためです。

これには、クライアントだけでなく、サーバー上で使用するサービスを提供する第三者も含まれます。プライバシーの観点から、サードパーティのライブラリ（NPM、Composer、NuGet からに含まれているものなど）についても理解しておくことが重要です。依存関係が境界外にデータを渡していますか？ロギング サービスまたはリモートでホストされるデータベースにデータを渡す際に、追加したライブラリが作成者の「スマートフォンのホーム」でもある場合は、ユーザーのプライバシーを侵害するおそれがあるため、監査が必要になります。通常、サーバーベースのサードパーティは、ユーザーデータをお客様に渡す必要があります。つまり、第三者が公開されるデータはお客様の管理下に入ります。一方、クライアント ベースのサードパーティ（ウェブサイトに含まれ、ユーザーのブラウザによって取得されるスクリプトまたは HTTP リソース）は、収集プロセスを経由することなく、ユーザーから直接一部のデータを収集できます。このモジュールのほとんどは、クライアントサイドのサードパーティを含め、ユーザーを公開対象にすることを選択したクライアントサイドのサードパーティを特定する方法に関するものです。デベロッパー側のメディエーションは限られるためです。ただし、サーバーサイドのコードから送信される通信を把握し、予期しない動作をログに記録またはブロックできるように、セキュリティを確保することを検討する価値はあります。具体的な方法については、ここでは説明しませんが、これはサーバーの設定によっても異なりますが、これはお客様のセキュリティとプライバシーに対する姿勢の一環です。

サードパーティに注意する必要がある理由

サードパーティのスクリプトや機能はきわめて重要です。ウェブ デベロッパーとしての目標は、そのようなものを見落とすのではなく統合することです。しかし、潜在的な問題があります。サードパーティのコンテンツによりパフォーマンスの問題が発生する可能性があります。また、信頼境界内で外部サービスを取り込むためにセキュリティの問題が発生する可能性があります。しかし、サードパーティのコンテンツもプライバシーの問題を引き起こす可能性があります。

ウェブ上のサードパーティ リソースについて考える場合、セキュリティの問題は、とりわけサードパーティが会社のデータを盗む可能性があること、プライバシーの問題とは対照的に考えると役立ちます。プライバシーの問題は、関与したサードパーティが同意なしにユーザーのデータを盗んだり取得したりする問題です。

セキュリティ問題の一例として、「ウェブ スキマー」がクレジット カード情報を盗みます。これは、ユーザーがクレジット カード情報を入力するページに含まれるサードパーティ リソースであり、クレジット カード情報を盗み、悪意のある第三者に送ってしまう可能性があります。こうしたスキマー スクリプトの作成者は、スクリプトを隠す場所を指定しようとするクリエイティブな作業に秀でています。概要の 1 つでは、サイトロゴ、ファビコン、ソーシャル メディア ネットワークで使用される画像、一般的なライブラリ（jQuery、Modernizr、Google タグ マネージャーなど）、サイトのウィジェット（チャット ウィンドウなど）、CSS ファイルなど、サードパーティのコンテンツでスキマー スクリプトが隠れている状況について説明しています。

プライバシーの問題はそれとは少し異なります。これらのサードパーティは、サービスの一環です。ユーザーの信頼を維持するには、ユーザーに信頼していただけるという確信が必要です。使用するサードパーティがユーザーに関するデータを収集し、それを悪用した場合、データの削除や発見が困難になる場合、データ侵害が困難になる場合、ユーザーの期待に反している場合、ユーザーはそのことをサードパーティだけでなく、お客様のサービスの信頼性の低下と認識する可能性があります。これはお客様の評判と関係です。だからこそ、サイトで使用しているサードパーティを信頼するかどうか、自問することが大事です。

サードパーティの例をいくつか挙げてください。

以下では「サードパーティ」について全般的に説明しましたが、実際にはさまざまな種類があり、それぞれがアクセスできるユーザーデータへのアクセスも異なります。たとえば、HTML に <img> 要素を追加して別のサーバーから読み込むと、そのサーバーに <iframe> や <script> 要素を追加する場合とは異なるユーザー情報が提供されます。これらは包括的なリストというよりも一例ですが、サイトで採用されているさまざまなタイプのサードパーティ製アイテムの違いを理解することは有益です。

クロスサイト リソースのリクエスト

クロスサイト リソースとは、<iframe> や <script> ではなく、別のサイトから読み込まれるサイト上のものを指します。たとえば、<img>、<audio>、<video>、CSS によって読み込まれるウェブフォント、WebGL テクスチャなどがあります。これらはすべて HTTP リクエストを介して読み込まれます。前述のように、HTTP リクエストには、別のサイトで以前に設定された Cookie、リクエスト元のユーザーの IP アドレス、参照 URL として現在のページの URL が含まれます。これまで、サードパーティのリクエストには、すべてデフォルトでこのデータが含まれていました。ただし、後述の「サードパーティのブラウザ保護について」で説明するように、さまざまなブラウザからサードパーティに渡されるデータを削減または分離する取り組みが行われています。

クロスサイト iframe の埋め込み

<iframe> を介してページに埋め込まれたドキュメント全体は、Cookie、IP アドレス、リファラーの 3 要素に加えて、ブラウザ API への追加アクセスをリクエストできます。<iframe>d ページで使用できる API と、アクセスをリクエストする方法はブラウザ固有であり、現在変更が行われています。埋め込みドキュメントでの API アクセスを制限またはモニタリングする現在の取り組みについては、以下の「権限に関するポリシー」をご覧ください。

クロスサイト JavaScript の実行

<script> 要素を含めると、ページの最上位のコンテキストでクロスサイト JavaScript が読み込まれ、実行されます。つまり、実行されるスクリプトは、独自のファーストパーティ スクリプトが実行するすべてのものに完全にアクセスできます。このデータは引き続きブラウザの権限によって管理されるため、ユーザーの位置情報をリクエストする場合などにはユーザーの同意が必要です。しかし、ページ内に存在する情報や JavaScript 変数として利用できる情報はすべて、このようなスクリプトによって読み取ることができます。これには、リクエストの一部としてサードパーティに渡される Cookie だけでなく、ご自身のサイトのみを対象とする Cookie も含まれます。同様に、ページに読み込まれたサードパーティのスクリプトは、独自のコードと同じ HTTP リクエストを実行できます。つまり、バックエンド API に対して fetch() リクエストを行ってデータを取得する可能性があります。

依存関係にサードパーティ ライブラリを含める

前述のように、サーバー側のコードにはサードパーティの依存関係も含まれる可能性があります。こうした依存関係は、その力では独自のコードと区別できません。GitHub リポジトリまたはプログラミング言語のライブラリ（npm、PyPI、composer など）から組み込んだコードは、他のコードと同じデータをすべて読み取ることができます。

サードパーティについて

そのためには、サードパーティ サプライヤーのリストと、そのプライバシー、データ収集、ユーザー エクスペリエンスの考え方とポリシーについて理解する必要があります。この理解は一連のトレードオフの一部になります。つまり、サービスがいかに有用で重要か、ユーザーにとって煩わしさや不便さ、要求がどれほどユーザーに不快感を与えるかとのバランスを取ることです。サードパーティのコンテンツは、サイト所有者が負担の大きい作業を取り除き、コア コンピテンシーに集中できるようにすることで価値をもたらします。そのため、このトレードオフを考慮し、ユーザー エクスペリエンスを向上させるためにユーザーの快適さとプライバシーを犠牲にすることにも価値があります。ユーザー エクスペリエンスとデベロッパー エクスペリエンスを混同しないようにすることが重要です。ただ、「開発チームにとってサービスを構築するのは簡単だった」はユーザーにとって説得力のないストーリーではありません。

理解する方法が監査のプロセスです。

第三者を監査する

第三者の業務を把握することが監査のプロセスです。これは、技術的にも非技術的にも、個々のサードパーティに対して、およびコレクション全体に対して行うことができます。

技術以外の監査を実行する

最初のステップは技術的なことではありません。サプライヤーのプライバシー ポリシーをお読みください。サードパーティのリソースを含める場合は プライバシーポリシーを確認してください内容が長く、法的テキストが多く、一部のドキュメントでは、以前のモジュールで特に警告されたアプローチの一部が使用される場合があります。たとえば、過度に一般的な記述で、収集されたデータを削除する方法やいつ削除するかについては明記されていません。ユーザーの視点では、第三者を含むサイト上で収集されるすべてのデータに、これらのプライバシー ポリシーが適用されることを認識することが重要です。すべてを正しく行ったとしても、目標を明確にし、データのプライバシーと機密性に関するユーザーの期待を超える場合、選択した第三者に対するすべての責任についてユーザーが責任を負うことがあります。ユーザーの信頼を損なうため、独自のポリシーでは伝えたくない内容がプライバシー ポリシーに記載されている場合は、別のサプライヤーがあるかどうかを検討します。

これは、後で説明する技術監査が相互に情報提供を行ううえで役立つ情報です。ビジネス上の関係を保つサードパーティのリソース（広告ネットワークや埋め込みコンテンツなど）については、把握しておく必要があります。ここは、非技術監査を始めるのに適しています。また、技術監査ではサードパーティが特定される可能性が高くなります。特に、ビジネス上の理由ではなく技術的な理由のために追加されたサードパーティ（外部コンポーネント、分析、ユーティリティ ライブラリ）が特定される可能性があります。また、そのリストは、ビジネスに特化したサードパーティのリストと結合される場合があります。ここでの目標は、サイトに追加する第三者が何を行っているかを理解しているとサイト所有者が理解し、必要な義務を果たしていることを確認するために、自社の法律顧問にこの第三者のインベントリを提示できるようにすることです。

技術監査を実施する

技術監査では、ウェブサイトの一部としてリソースをその場で使用することが重要です。つまり、テストハーネスに依存関係を読み込んで検査しないでください。テストモードや開発モードではなく、公共のインターネット上にデプロイされ、依存関係が実際のウェブサイトの一部としてどのように機能するかを確認してください。自分のウェブサイトを新規ユーザーとして 表示することが非常に有益ですログインせずに、契約が保存されていない新しいプロファイルでブラウザを開き、サイトにアクセスします。

ご自身のサイトで新しいアカウントを作成します（ユーザー アカウントを提供した場合）。デザインチームはこの新規ユーザー獲得プロセスを UX の観点からオーケストレートしますが、プライバシーの観点からアプローチを示すこともできます。利用規約、Cookie に関する警告、プライバシー ポリシーのページでも、単に [同意する] をクリックするのではなく、個人情報を開示したりトラッキング Cookie をもらったりすることなく、ご自身のサービスを使用するよう設定し、できるかどうか、どの程度難しいかを確認します。また、ブラウザのデベロッパー ツールで、アクセスされているサイトと、それらのサイトに渡されているデータを確認することも有用です。デベロッパー ツールには、個別の HTTP リクエストのリスト（通常は [Network] セクション内）が用意されており、タイプ（HTML、CSS、画像、フォント、JavaScript、JavaScript によって開始されたリクエスト）ごとにグループ化されたリクエストを確認できます。また、新しい列を追加して各リクエストのドメインを示すと、連絡を受けている場所の数を示すことができます。また、[サードパーティ リクエスト] チェックボックスでサードパーティのみを表示することもできます。（また、Content-Security-Policy レポートを使用して継続的な監査を実施すると便利です。これについては後述します）。

Simon Hearne の「Request Map Generator」ツールも、公開されているページが発行するすべてのサブリクエストの概要を把握するのに便利です。

また、ここでは、非技術監査の一環として特定された、業務に特化した第三者（つまり、リソースを使用するために財務上の関係がある企業のリスト）を含めることもできます。ここでの目標は、お客様が使用していると思われるサードパーティのリスト（財務記録や法律記録に基づく）と、実際に使用しているリスト（ウェブサイトがどのサードパーティ HTTP リクエストからリクエストしているかを調べて）を照合することです。ビジネス用サードパーティごとに、どの技術的なアウトバウンド リクエストが行われているのかを特定できる必要があります。取引関係によって特定された第三者の技術監査でリクエストを特定できない場合は、その理由を解明し、テストの指針とすることが重要です。たとえば、サードパーティのリソースが特定の国、特定のデバイスタイプ、またはログインしているユーザーのみに読み込まれる場合があります。これにより、監査するサイト領域のリストが拡大し、すべてのアウトバウンド アクセスを確認できます。（あるいは、料金を支払っているのに使用していないサードパーティのリソースを特定する場合もあります。常に財務部門を助けるはずです）。

監査の対象となる第三者へのリクエストを絞り込んだら、個々のリクエストをクリックすると、そのすべての詳細情報と、そのリクエストに渡されたデータの詳細が表示されます。また、コードによって開始されたサードパーティ リクエストがその後に、他の多くのサードパーティ リクエストを開始することもよくあります。こうしたサードパーティは、お客様のプライバシー ポリシーにも「インポート」されます。このタスクは手間がかかりますが、価値があり、既存の分析に挿入できることがよくあります。フロントエンド開発チームは、パフォーマンス上の理由で（おそらく WebPageTest や Lighthouse などの既存のツールを利用して）リクエストを監査しているはずです。データとプライバシーの監査をそのプロセスに組み込むと、これが簡単になります。

web.dev リクエスト マップ。
他のサードパーティ サイトをリクエストするサードパーティ サイトを示す、web.dev のリクエストマップ（大幅に簡素化）。

すべきこと

新しいユーザー プロファイルでブラウザを開き、ログインせずに、契約が保存されないようにします。次に、ブラウザ開発ツールの [ネットワーク] パネルを開き、送信されるリクエストをすべて表示します。各リクエストのドメインを示す新しい列を追加し、[サードパーティのリクエスト] チェックボックスをオンにして、サードパーティが存在する場合のみ表示します。以下の手順を行います。

  • サイトにアクセスします。
  • ユーザー アカウントを提供する場合は、新しいアカウントに登録します。
  • 作成したアカウントを削除してみてください。
  • サイトに対して通常の操作を 1 つか 2 つ行います（実際の操作はサイトの機能によって異なりますが、多くのユーザーが行う一般的な操作を選択してください）。
  • 特にサードパーティの依存関係が関係していることがわかっているアクションを 1 つか 2 つ実行します。これには、ソーシャル メディアへのコンテンツの共有、購入手続きフローの開始、別のサイトのコンテンツの埋め込みなどが含まれます。

これらの各タスクを行うときは、説明されている [ネットワーク] パネルで、自分のものではないドメインからリクエストされたリソースの記録を作成します。これらは一部のサードパーティです。これを行うには、ブラウザのネットワーク ツールを使用して、ネットワーク リクエスト ログを HAR ファイルにキャプチャすることをおすすめします。

HAR ファイルとキャプチャ

HAR ファイルは、ページによって送信されるすべてのネットワーク リクエストの標準化された JSON 形式です。特定のページの HAR ファイルを取得するには、次を実行します。

Chrome

ブラウザの DevTools を開き（[メニュー] > [その他のツール] > [デベロッパー ツール]）、[ネットワーク] パネルに移動してページを読み込み（または更新）、右上の「スロットリングなし」プルダウン メニューの近くにある下矢印の保存シンボルを選択します。

[HAR をダウンロード] 記号がハイライト表示された Chrome DevTools のネットワーク パネル。
Firefox

ブラウザのデベロッパー ツール（[メニュー] > [その他のツール] > [ウェブ デベロッパー ツール]）を開き、[ネットワーク] パネルに移動してページを読み込み（または更新）し、スロットリング プルダウン メニューの右上にある歯車アイコンを選択します。メニューから [Save All As HAR] を選択します**。

Firefox デベロッパー ツールのネットワーク パネル。[Save All As Har] オプションがハイライト表示されている。
Safari

ブラウザのデベロッパー ツールを開きます（[メニュー] > [開発] > [Web Inspector を表示]）。[開発] メニューがない場合は、メニューバーの [メニュー] > [Safari] > [設定] > [詳細設定] > [開発] メニューを表示から有効にします。[ネットワーク] パネルでページを読み込み（または更新）し、右上（ウィンドウの [Preserve Log] の右側）の [エクスポート] を選択します。

[HAR エクスポート] オプションがハイライト表示された Safari Web Inspector Network パネル。

さらに詳細に、第三者に渡す内容を（リクエストのセクションで）記録することもできますが、このデータは多くの場合、難読化され、効果的に解釈できません。

サードパーティを統合する際のベスト プラクティス

サイトで使用する第三者について、独自のポリシーを設定できます。使用する広告プロバイダをその手法に基づいて変更する、Cookie に関する同意のポップアップを迷惑または煩わしいものにするかどうか、サイトでソーシャル メディアのボタンを使用する、メール内のリンクのトラッキング リンク、utm_campaign のリンクをツイートで Google アナリティクスでトラッキングするかどうかなどを設定できます。サイトを開発する際に考慮すべき点の一つは、分析サービスのプライバシーとセキュリティの体制です。一部の分析サービスでは、プライバシー保護と引き換えに明示的に指定されているものがあります。多くの場合、プライバシー保護を強化するサードパーティのスクリプトを使用する方法があります。あなたは、ユーザーのプライバシーを向上させ、サードパーティ データ収集からユーザーを保護することを最先端とするチームではなく、すでに解決策があるかもしれません。最後に、多くのサードパーティ プロバイダは、以前よりもデータ収集の問題に敏感です。多くの場合、追加の機能やパラメータが追加され、ユーザー保護機能を強化できます。次に例を示します。

ソーシャル メディアの共有ボタンを追加するとき

HTML ボタンを直接埋め込むことを検討してください。サイト https://sharingbuttons.io/ に、適切に設計されたサンプルがあります。 通常の HTML リンクを追加することもできます。この場合のトレードオフは、「共有数」の統計情報を失い、Facebook の分析で顧客を分類できなくなることです。これは、サードパーティ プロバイダを利用することと、受け取る分析データが少なくなることとのトレードオフの一例です。

より一般的には、サードパーティが提供するなんらかのインタラクティブ ウィジェットを埋め込む場合は、多くの場合、そのサードパーティへのリンクを提供できます。これは、サイトにインライン機能がないことを意味しますが、サードパーティとのデータ共有に関する決定を、ユーザーが任意にやり取りするかどうかを選択できます。

たとえば、次のように Twitter と Facebook のリンクを追加して、 Logging.example.com でサービスを共有できます。

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

なお、Facebook では共有する URL を指定でき、Twitter では URL とテキストを指定できます。

動画を埋め込むとき

動画ホスティング サイトから動画を埋め込む場合は、埋め込みコード内でプライバシー保護のオプションを探してください。 たとえば、YouTube の場合、埋め込み URL の youtube.com を www.youtube-nocookie.com に置き換えて、埋め込みページを閲覧するユーザーに配置された Cookie がトラッキングされないようにします。また、YouTube 自体から共有/埋め込みリンクを生成するときに [プライバシー強化モードを有効にする] をオンにすることもできます。これは、サードパーティが提供するユーザー保護を強化するモードを使用する良い例です。（詳しくは https://support.google.com/youtube/answer/171780 をご覧ください）。YouTube 向けの他の埋め込みオプションも詳しく説明しています。

他の動画サイトにはこれに関する選択肢が限られており、この記事の執筆時点では、TikTok にはトラッキングなしで動画を埋め込む方法がありません。動画を自分でホストすることもできます（別の方法を使用します）。ただし、特に多くのデバイスをサポートするには、かなりの作業が必要になります。

前述したインタラクティブ ウィジェットと同様に、多くの場合、埋め込み動画をサイトへのリンクに置き換えることができます。この場合、動画はインラインで再生されないため、インタラクティブ性が低下しますが、ユーザーと一緒に視聴するかどうかの選択はできなくなります。これは、「ファサード パターン」の例として使用できます。ファサード パターンは、インタラクティブなコンテンツを、ユーザーの操作によってトリガーするコンテンツを動的に置き換えるための名称です。埋め込まれた TikTok 動画は、TikTok 動画ページへのプレーン リンクに置き換えることができますが、少し手を加えれば、動画のサムネイルを取得して表示し、リンクにすることもできます。選んだ動画プロバイダが、トラッキングなしで動画を埋め込む簡単な方法をサポートしていない場合でも、多くの動画ホストが oEmbed をサポートしています。oEmbed は、動画や埋め込みコンテンツへのリンクを提供すると、サムネイルやタイトルなど、その動画に関する詳細をプログラムによって返します。TikTok は oEmbed をサポートしています（詳しくは https://developers.tiktok.com/doc/embed-videos をご覧ください）。つまり、https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 を使用して、TikTok 動画 https://www.tiktok.com/@scout2015/video/6718335390845095173 へのリンクを（手動またはプログラムによって）JSON メタデータに変換し、表示するサムネイルを取得できます。たとえば、WordPress はこれを使用して、埋め込みコンテンツの oEmbed の情報をリクエストします。これをプログラムによって使用して、「ファサード」をインタラクティブに表示できます。ファサードは、ユーザーが動画をクリックしたときに、インタラクティブな動画の埋め込みやリンクに切り替わります。

分析スクリプトを埋め込む場合

アナリティクスは、ユーザーに関する情報を収集して分析することを目的としています。分析システムは基本的に、アクセスやユーザーに関するデータを収集して表示するサービスです。この処理は、実装を容易にするために Google アナリティクスなどのサードパーティ サーバー上で行われます。https://matomo.org/ などの自己ホスト型分析システムもありますが、これはサードパーティのソリューションを使用するよりも手間がかかります。ただし、このようなシステムを独自のインフラストラクチャで実行すれば、独自のエコシステムを離れることがないため、データ収集を減らすことができます。一方、そのデータの管理、削除、ポリシーの設定は、お客様側で行う必要があります。クロスサイト トラッキングに関する懸念のほとんどは、それがひそかに秘密的に行われた場合、またはデータ収集をまったく必要としないサービスの利用による副作用として生じます。分析ソフトウェアは、サイト所有者にユーザーについての情報を提供する目的でデータを収集するように設計されています。

従来から、巨大な漁網など、あらゆるものに関するあらゆるデータを収集し、後で分析して興味深いパターンを見つけるという手法がありました。このような考え方は、このコースのパート 1 で説明したデータ収集に関する不安感や不安感を生み出しています。現在では多くのサイトでは、まずどのような質問をすべきかを判断し、次に具体的なデータを集めてその答えを導き出しています。

自分のサイトと他のサイトでサードパーティ サービスが使用されており、そのサービスがサイトに JavaScript を追加して動作し、各ユーザーに Cookie を設定する場合、そのサービスが望ましくないクロスサイト認識（サイト間でのユーザーのトラッキング）を行っている可能性を考慮することが重要です。そうではない場合もありますが、ここでのプライバシー保護の方針は、正当な理由がない限り、このようなサードパーティ サービスが実際にクロスサイト トラッキングを行っていると仮定することです。これ自体はこのようなサービスを回避する理由にはなりませんが、サービスを使用する場合のトレードオフを評価する際に考慮する必要があります。

分析におけるトレードオフは、これまでは分析を使用するかどうかを決めることしかできませんでした。つまり、分析情報と計画と引き換えにすべてのデータを収集してプライバシーを侵害するか、分析情報を完全に手放すかです。しかし、現在はこの限りではなく、しばしばこの 2 つの極端の中間に位置することがわかっています。収集するデータを制限し、保存量と保存期間を短縮するための構成オプションについては、分析プロバイダにお問い合わせください。前述の技術監査の記録があるため、その監査の関連するセクションを再実行して、これらの構成を変更すると収集されるデータの量が実際に減少していることを確認できます。既存のサイトでこの移行を行う場合は、これにより、ユーザー向けに記述できる定量化可能な尺度が得られます。たとえば、Google アナリティクスにはオプトイン（デフォルトでオフ）のプライバシー機能が多数用意されています。その多くは地域のデータ保護法を遵守するために役立つ場合があります。Google アナリティクスを設定するときに考慮すべきオプションとして、収集したデータの保持期間（[管理] > [トラッキング情報] > [データ保持]）をデフォルト値の 26 か月よりも短く設定することや、部分的な IP 匿名化などの技術的なソリューションを有効にすることなどがあります（詳しくは https://support.google.com/analytics/answer/9019185 をご覧ください）。

プライバシーを保護した方法でサードパーティを使用する

ここまで、アプリケーションの設計段階でユーザーをサードパーティから保護する方法を説明しました。その一方で、そのアプリケーションの動作を計画する段階です。特定のサードパーティを使用しないという判断もこの計画の一部であり、使用状況の監査もこのカテゴリに分類されます。つまり、プライバシーの姿勢について判断することです。しかし、こうした判断は本質的にそれほど詳細なものではありません。特定のサードパーティを利用するかどうか、または選択しないかどうかは、微妙な判断ではありません。特定のサードパーティ サービスを使用する必要がある、または使用を計画しているが、意図的か偶発的かにかかわらず、プライバシーを侵害する傾向を軽減する必要性が生じる可能性は大いにあります。これは、「ビルド時」にユーザーを保護するタスクで、予期しない損害を減らすための安全保護対策を追加します。これらはすべて、ページの提供時に指定でき、ユーザー エージェントが特定のプライバシーまたはセキュリティの立場を取ることを示唆または指示する新しい HTTP ヘッダーです。

リファラー ポリシー

すべきこと

strict-origin-when-cross-origin または noreferrer ポリシーを設定すると、他のサイトがリファラー ヘッダーを受け取ったり、他のサイトがページによってサブリソースとして読み込んだりすることを防止できます。

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

サーバーサイドの場合（Express の場合など）:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

必要に応じて、特定の要素またはリクエストにラクサー ポリシーを設定します。

ユーザーのプライバシーを保護する理由

デフォルトでは、ブラウザが行う各 HTTP リクエストは Referer ヘッダーで渡します。このヘッダーには、リクエストを開始したページの URL（リンク、埋め込み画像、スクリプト）が含まれます。これはプライバシーの問題になる可能性があります。URL に個人情報が含まれることがあり、第三者がアクセスできる URL からその URL に個人情報が渡されるからです。Web.dev で、非公開データを含む URL の例をいくつか紹介しています。ユーザーが https://social.example.com/user/me@example.com からサイトにアクセスしたことを知ることで、そのユーザーが誰かがわかります。これは明らかな漏洩です。しかし、URL 自体が個人情報を公開していない場合でも、この特定のユーザー（ログインしている場合ならご存じかもしれません）が別のサイトから来たことは明らかになるため、このユーザーがその別のサイトにアクセスしたことがわかります。これにより、ユーザーの閲覧履歴について知っておく必要のない情報が漏洩することになるからです。

Referrer-Policy ヘッダーに（正しいスペルで）指定すると、参照 URL の一部または一切が渡されないようにすることができます。 MDN には詳細な情報が掲載されていますが、ほとんどのブラウザでは仮定値 strict-origin-when-cross-origin がデフォルトで採用されています。つまり、参照 URL はオリジンとしてサードパーティにのみ渡されるようになりました（https://web.dev/learn/privacy ではなく https://web.dev）。これは、何も操作しなくても便利なプライバシー保護です。ただし、Referrer-Policy: same-origin を指定して、リファラー情報が第三者に渡されないようにする（または、独自のオリジンを含む誰にも渡さないように Referrer-Policy: no-referrer を指定）することで、これをさらに強化できます。（これはプライバシーとユーティリティのバランスの好例です。新しいデフォルトは以前よりもはるかにプライバシーを保護しつつ、分析プロバイダなどの任意の第三者に大まかな情報を提供します）。

また、ブラウザのデフォルトに依存するのではなく、ポリシーの内容を正確に把握できるため、このヘッダーを明示的に指定すると便利です。ヘッダーを設定できない場合は、<head>: <meta name="referrer" content="same-origin"> でメタ要素を使用して HTML ページ全体のリファラー ポリシーを設定できます。特定の第三者が関係する場合は、<script>、<a>、<iframe> などの個々の要素に referrerpolicy 属性を設定することもできます。<script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

コンテンツ セキュリティ ポリシー

Content-Security-Policy ヘッダー（多くの場合「CSP」と呼ばれます）で、外部リソースを読み込むことができる場所を指定します。これは主に、クロスサイト スクリプティング攻撃やスクリプト インジェクションを防ぐセキュリティ目的で使用されますが、定期的な監査と併用すると、指定した第三者がデータを渡すことができる場所が制限される可能性もあります。

これは、ユーザー エクスペリエンスが低下する可能性があります。サードパーティ スクリプトがリストにないオリジンから依存関係の読み込みを開始した場合、そのリクエストはブロックされ、スクリプトが失敗し、アプリケーションが失敗する可能性があります（または、少なくとも JavaScript に失敗するフォールバック バージョンに縮小されます）。これは、セキュリティのために CSP が実装されている場合に有用です。これは、クロスサイト スクリプティング問題からの保護という通常の目的です（このためには、厳格な CSP を使用します）。ページで使用されるすべてのインライン スクリプトを把握したら、それらのリストを作成し、それぞれにハッシュ値を計算するか、ランダムな値（「ノンス」と呼ばれます）を追加して、ハッシュのリストをコンテンツ セキュリティ ポリシーに追加できます。これにより、リストにないスクリプトが読み込まれなくなります。これは、サイトの制作プロセスに組み込む必要があります。ページのスクリプトにノンスを含めるか、ビルドの一環としてハッシュを計算する必要があります。詳しくは、strict-csp に関する記事をご覧ください。

幸い、ブラウザは関連するヘッダー Content-Security-Policy-Report-Only をサポートしています。このヘッダーを指定すると、指定されたポリシーに違反するリクエストはブロックされず、指定された URL に JSON レポートが送信されます。このようなヘッダーは Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ のようになります。ブラウザが 3p.example.com 以外の場所からスクリプトを読み込むと、そのリクエストは成功しますが、指定した report-uri にレポートが送信されます。通常、ポリシーを実装する前にテストするために使用されますが、「継続的な監査」を実施する方法として使用することもできます。前述の定期的な監査に加えて、CSP レポートを有効にして、予期しないドメインが表示されるかどうかを確認できます。これは、サードパーティ リソースが独自のサードパーティ リソースを読み込んでいて、考慮および評価する必要があることを意味します。（また、クロスサイト スクリプティングの悪用がセキュリティ境界をすり抜けている可能性もあるため、これも把握しておくことが重要です）。

Content-Security-Policy は、使用する複雑で繊細な API です。これは既知のことであり、同じ目標を達成できるものの、それほど複雑ではない CSP の「次世代」の構築が進行中です。まだ準備ができていませんが、今後の方向性を確認すること（または、設計に関与して支援すること）については、https://github.com/WICG/csp-next で詳細をご確認ください。

すべきこと

表示されるページに HTTP ヘッダー Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control を追加します。その URL に投稿された JSON を保存します。保存されているデータを確認して、他のユーザーがウェブサイトにアクセスしたときにリクエストするサードパーティ ドメインのコレクションを取得します。 必要なドメインをリストするよう Content-Security-Policy-Report-Only ヘッダーを更新して、そのリストが変更されるタイミングを確認します。

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

理由

これは継続的な技術監査の一環です。初期の技術監査では、サイトでユーザーデータを共有または受け渡す第三者のリストが提供されます。このヘッダーを使用すると、現在どの第三者にアクセスしているかがページ リクエストで報告され、変更の推移を追跡できます。これにより、既存の第三者が行った変更を通知できるだけでなく、技術監査に追加されていない新たに追加された第三者にも通知されます。ヘッダーを更新して、想定されるドメインに関するレポートを停止するようにすることが重要ですが、手動の技術監査をときどき繰り返すことも重要です（Content-Security-Policy アプローチでは、渡されるデータにフラグが設定されず、リクエストが発行されたことのみを示すためです）。

毎回のページ、またはすべてのページに追加する必要はありません。ヘッダーを取得するページ レスポンスの数を減らして、レポートの代表サンプルが過剰にならないようにします。

権限ポリシー

Permissions-Policy ヘッダー（Feature-Policy という名前で導入）は、概念的には Content-Security-Policy と似ていますが、強力なブラウザ機能へのアクセスを制限します。たとえば、加速度計、カメラ、USB デバイスなどのデバイス ハードウェアの使用を制限したり、全画面表示や同期 XMLHTTPRequest の使用の権限など、ハードウェア以外の機能を制限したりできます。こうした制限は、トップレベルのページ（読み込んだスクリプトがこれらの機能を使用できなくなります）、または iframe 経由で読み込まれるサブフレームされたページに適用できます。この API 使用の制限は、実際にはブラウザのフィンガープリントに関するものではなく、サードパーティによる煩わしい行為（強力な API の使用、権限ウィンドウのポップアップなど）を禁止するためのものです。これは、ターゲット プライバシー脅威モデルで「侵入」と定義されています。

Permissions-Policy ヘッダーは、（対象物、許可されたオリジン）のペアのリストとして指定されます。

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

この例では、元の example.com のページ（「self」）と <iframe> に対して、JavaScript から navigator.geolocation API の使用を許可します。このページとすべてのサブフレームで全画面 API を使用できるようになり、このページを含むいずれのページでもカメラを使用して動画情報を読み取ることが禁止されます。詳しくは、こちらの例をご覧ください。

Permissions-Policy ヘッダーで処理される機能のリストは多く、流動的なものになる可能性があります。現在、このリストは https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md で管理されています。

すべきこと

Permissions-Policy をサポートしているブラウザでは、サブフレーム内の強力な機能をデフォルトで許可しないため、有効にするにはユーザーが操作する必要があります。 このアプローチはデフォルトでは非公開です。サイト上のサブフレームにこれらの権限が必要になった場合は、選択的にサブフレームを追加できます。ただし、デフォルトではメインページに適用される権限ポリシーはないため、メインページから読み込まれるスクリプト（サードパーティのスクリプトを含む）は、これらの機能の使用が制限されません。そのため、制限付きの Permissions-Policy をすべてのページに適用し、ページが必要とする機能を徐々に追加していくと便利です。

Permissions-Policy が影響を与える強力な機能の例として、ユーザーの位置情報のリクエスト、センサー（加速度計、ジャイロスコープ、磁力計など）へのアクセス、全画面表示の権限、ユーザーのカメラとマイクへのアクセスのリクエストなどがあります。機能の全機能の（変更される）リストは上のリンクから確認できます。

残念ながら、デフォルトですべての機能をブロックして、選択的に再度許可するには、ヘッダーにすべての機能をリストする必要がありますが、これはあまり意味がなく、それでも、このような Permissions-Policy ヘッダーから始めるのがよいでしょう。permissionspolicy.com/ には、このようなヘッダーを作成するための便利なクリック可能なジェネレータが用意されています。これを使用して、すべての機能を無効にするヘッダーを作成します。

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

ウェブブラウザに組み込まれているプライバシー機能について理解する

「ビルド時」と「設計時」の保護に加えて、「実行時」に行われるプライバシー保護もあります。つまり、ユーザーを保護するために、ブラウザ自体に実装されるプライバシー機能です。これらはプロダクトの機能であり、サイト デベロッパーとして直接管理または利用できる機能ではありませんが、ブラウザにおけるプロダクトの決定がサイトに影響する可能性があるため、確認しておく必要がある機能です。例として、このようなブラウザ保護がサイトに与える影響を一例として説明すると、ページ設定を続行する前にサードパーティの依存関係の読み込みを待つクライアントサイドの JavaScript があり、そのサードパーティの依存関係の読み込みがまったく行われない場合、ページの設定が完了せず、ユーザーに表示される半読み込み済みのページが表示される可能性があります。

Safari のインテリジェント トラッキング防止機能（および基盤となる WebKit エンジン）と、Firefox（およびそのエンジンである Gecko）の拡張トラッキング保護です。これらはすべて、サードパーティがユーザーの詳細なプロファイルを作成することを困難にします。

プライバシーに関するブラウザのアプローチは頻繁に変更されるため、常に最新の状態に保つことが重要です。以下の保護機能のリストは、執筆時点で正しいものです。ブラウザによっては他の保護機能を実装することもできますが、このリストはすべてを網羅しているわけではありません。変更への対応方法については、ベスト プラクティスに関するモジュールをご覧ください。プロジェクトに影響する可能性がある変更については、今後のブラウザ バージョンで必ずテストしてください。シークレット モードやシークレット ブラウジング モードでは、ブラウザのデフォルト設定とは異なる設定が実装されている場合があります（このようなモードではサードパーティ Cookie がデフォルトでブロックされることがあります）。そのため、シークレット モードでのテストは、シークレット ブラウジングを使用していないユーザーの一般的なブラウジング エクスペリエンスを反映していない場合があります。また、さまざまな状況で Cookie をブロックすると、Cookie だけでなく、window.localStorage などの他のストレージ ソリューションもブロックされる可能性があります。

Chrome

  • サードパーティ Cookie は、今後ブロックされる予定です。現時点では、これらのブロックはデフォルトでブロックされていません（ただし、ユーザーが有効にできます）。https://support.google.com/chrome/answer/95647 に詳細が記載されています。
  • Chrome のプライバシー機能、特に Google やサードパーティのサービスと通信する Chrome の機能については、privacysandbox.com/ をご覧ください。

エッジ

  • サードパーティ Cookie は、デフォルトではブロックされません（ユーザーが有効にできます）。
  • Edge のトラッキング防止機能では、アクセスしていないサイトのトラッカーはブロックされ、既知の有害なトラッカーはデフォルトでブロックされます。

Firefox

  • サードパーティ Cookie は、デフォルトではブロックされません（ユーザーが有効にできます）。
  • Firefox の保護強化機能では、トラッキング Cookie、フィンガープリント スクリプト、クリプトマイナー スクリプト、既知のトラッカーをデフォルトでブロックします。（詳しくは、https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track をご覧ください）。
  • サードパーティ Cookie はサイトによって制限されるため、各サイトには基本的に個別の Cookie の JAR ファイルがあり、サイト間で関連付けることはできません（Mozilla ではこれを「Total Cookie Protection」と呼んでいます）。

ブロックされる可能性のあるコンテンツの詳細を確認し、問題をデバッグするには、アドレスバーの盾のアイコンをクリックするか、Firefox（パソコンの場合）で about:protections にアクセスしてください。

Safari

  • サードパーティ Cookie はデフォルトでブロックされます。
  • Safari のインテリジェント トラッキング防止機能機能の一環として、Safari では、他のページに渡される参照 URL を特定のページではなくトップレベル サイトとして指定しています（https://something.example.com/this/specific/page ではなく https://something.example.com）。
  • ブラウザの localStorage データは 7 日後に削除されます。

（https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ にこれらの機能がまとめられています）

何がブロックされる可能性があるかを把握し、問題のデバッグに役立てるには、Safari のデベロッパー メニュー（パソコンの場合）で [インテリジェント トラッキング防止デバッグモード] を有効にします。（詳しくは、https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ をご覧ください）。

API の提案

新しい API が必要な理由

ブラウザ サービスの新しいプライバシー保護機能とポリシーはユーザーのプライバシー保護に役立ちますが、課題も伴います。多くのウェブ技術は、他の目的のために設計、使用されているものの、クロスサイト トラッキングに使用できます。たとえば、Google が日常的に使用する ID 連携システムの多くは、サードパーティ Cookie に依存しています。現在パブリッシャーが収益のために利用している多くの広告ソリューションは、サードパーティ Cookie の上に構築されています。不正行為検出ソリューションの多くは、フィンガープリントに依存しています。サードパーティ Cookie とフィンガープリントが廃止されると、これらのユースケースはどうなりますか？

ブラウザにとって、ユースケースを区別し、プライバシーを侵害する用途と他の用途を確実に区別することは、困難でエラーが発生しやすくなります。そのため、主要なブラウザのほとんどが、ユーザーのプライバシーを保護するために、サードパーティの Cookie とフィンガープリントをブロックしているか、ブロックする予定である理由です。

新たなアプローチが必要です。サードパーティ Cookie が段階的に廃止され、フィンガープリントが軽減されるなか、デベロッパーはユースケースに対応しつつ、プライバシーを保護して設計された専用 API を必要としています。目標はクロスサイトトラッキングには 使用できない API を設計し構築することです前のセクションで説明したブラウザ機能とは異なり、これらの技術はクロスブラウザ API になることを目指しています。

API 提案の例

次のリストは包括的なものではなく、現在議論されている内容の一部です。

サードパーティ Cookie に基づく技術に代わる API 提案の例:

パッシブ トラッキングに基づく技術に代わる API 提案の例:

サードパーティ Cookie のない将来的に他の API で構築できるようになる他の提案の例は次のとおりです。

さらに、従来のブラウザ固有の隠れたトラッキングの軽減を試みる、別のタイプの API 提案が登場しています。その一例が、プライバシー バジェットです。このようにさまざまなユースケースにおいて、Chrome が当初提案した API はプライバシー サンドボックスという総称で使用されています。

Global-Privacy-Control は、収集された個人データが他のサイトと共有されたくないことをユーザーが希望するサイトに伝えることを目的としたヘッダーです。この機能は、廃止された「トラッキング拒否」に類似しています。

API 提案のステータス

これらの API 提案のほとんどは、まだデプロイされていないか、テストのためにフラグの背後または限られた環境にのみデプロイされています。

公開段階での検討は重要です。ブラウザ ベンダーとデベロッパーは、こうした API が役立つかどうかや、仕様どおりに動作するかどうかについて、議論と経験を集めます。デベロッパー、ブラウザ ベンダー、その他のエコシステムアクターは、このフェーズを使用して API の設計を反復処理します。

提案される新しい API の最新情報は、GitHub で公開しているプライバシー グループの提案リストでご確認いただけます。

これらの API を使用する必要はありますか？

製品がサードパーティ Cookie やフィンガープリントなどの技術の上に直接構築されている場合は、これらの新しい API を実際に試してみて、議論や API 設計に独自の経験を投稿する必要があります。それ以外の場合は、この記事の執筆時点でこれらの新しい API の詳細をすべて理解している必要はありませんが、今後の流れを把握しておくことは有益です。