サードパーティとは
ウェブサイトが完全に自己完結していることはめったにありません。HTTP Web Almanac によると、ほとんどのウェブサイト（約 95%）にサードパーティのコンテンツが含まれています。
Almanac では、第三者のコンテンツを、さまざまな組織が広く使用している、共有のオリジンでホストされているものとして定義しています 複数のサイトにアクセスでき、個々のサイト所有者の影響を受けない場合があります。画像のほか、動画、フォント、スクリプトなどのメディアがこれに該当します。 画像とスクリプトは、他の要素を組み合わせたものよりも重要です。第三者のコンテンツはサイトの開発に 必須ではありませんが 可能性はあります。ウェブフォント 動画、広告、JavaScript ライブラリの埋め込み iframeたとえば、Google Fonts が提供するウェブフォントを使用している場合や、 または Google アナリティクスでの分析の測定ソーシャル ネットワークから [いいね] ボタンや [ログインでログイン] ボタンを追加した可能性があります。 地図や動画を埋め込むか、サードパーティのサービスを介してショッピングの購入を処理する場合。エラーやトラフィックを追跡して 独自の開発チーム用のロギングをモニタリングできます。
プライバシー上の理由から、少し異なり広い範囲での定義、すなわち「サードパーティのリソース」と 共通のオリジンから提供され、図のように広く使用されていますが、 警告します。サードパーティの作成者情報の側面は、 ユーザー防ぐことができます。これにより、どのようなリスクが存在するかを検討し、 リスクに基づいてサードパーティ リソースを管理します。すでに説明したように、これらのことは、コンテキストを理解し、 必要なトレードオフとその意味を理解できます
「サードパーティのリソース」について話すとき、これが意味するところとまったく異なります一般的に、ファーストパーティと 「第三者」とは、何かが使用されるコンテキストに関するものです。別のウェブサイトから読み込まれたスクリプトがサードパーティのものである リソースであり、スクリプトを読み込む HTTP リクエストに Cookie が含まれている場合がありますが、これらの Cookie は実際には「サードパーティ Cookie」ではありません。 単なる Cookie で、「サードパーティ」かまたは「自社」呼び出すかどうかによって、スクリプトが またはスクリプト オーナーのサイトのページです。
第三者のリソースを利用する理由
サードパーティは、サイトに機能を追加するための優れた方法です。ユーザーに公開されている機能や デベロッパーはエラー追跡などの機能を使用できますが、開発の負荷が軽減され、スクリプト自体がメンテナンスされます。 （対象サービスの開発チーム）によって管理されます。これらはすべて、ウェブのコンポーザビリティにより適切に機能します。 パーツを組み合わせて、合計よりも大きな 1 つを作り上げることができます。
HTTP Archive の Web Almanac にはわかりやすい説明があります。
サードパーティは、画像、動画、ファイルのコレクションを フォント、ツール、ライブラリ、ウィジェット、トラッカー、広告など、ウェブページに埋め込むことができるあらゆるものを利用できます。これにより、 コンテンツを作成してウェブに公開できるようにしましたサードパーティがなければ、 豊かで没入感のある複雑なプラットフォームではなく、退屈なテキストベースの学術的メディアであり、生活に不可欠なものになる 多くの人が関わっています
サードパーティ リソースでできること
一部の情報へのアクセス
ウェブサイトでサードパーティのリソースを使用すると、内容にかかわらず、一部の情報がそのサードパーティに渡されます。 たとえば、別のサイトの画像を含めると、ユーザーのブラウザが実行する HTTP リクエストはリファラーを渡します。 ヘッダーにページの URL とユーザーの IP アドレスを追加します。
クロスサイト トラッキング
同じ例を見てみましょう。サードパーティ サイトから画像が読み込まれるときに、その画像に Cookie が含まれることがあります。 ユーザーが次回その画像をリクエストしたときに、第三者に返送されます。つまりサードパーティは サービスがサイト上で使用されている場合に、そのサービスから Cookie（場合によってはそのユーザーの一意の ID を含む）が返送されます。つまり ユーザーがサイト（またはそのサードパーティのリソースを含む他のサイト）に次回アクセスしたときに、 ID Cookie が再送信されます。これにより、サードパーティは、そのユーザーがアクセスしたサイト（お客様のサイト、 ウェブ全体で同じサードパーティ リソースを使用します。
これをクロスサイト トラッキングと呼びます。クロスサイト トラッキングを使用すると、多くのウェブサイトで ウェブサイトはすべて、同じ第三者からのリソースを使用しています。そのようなリソースには、フォント、画像、スタイルシートなどがあります。これらはすべて静的なリソースです。 また、スクリプト、ソーシャル メディアのボタン、広告などの動的なリソースを使用することもできます。含まれるスクリプトでは、 というのは、動的であるためです。ユーザーのブラウザと環境を検査し、そのデータを送信元に返すことができます。 ソーシャル メディアの埋め込みや 広告または共有ボタンです人気のあるウェブサイトの Cookie バナーの詳細を見ると、その組織のリストが表示されています。 : ユーザーにトラッキング Cookie を追加してアクティビティの全体像を構築し、ユーザーのプロフィールを作成する場合があります。そこで、 数百個に及ぶこともあります。サードパーティが無料でサービスを提供している場合、 なぜなら、このデータを収集して収益化しているからです。
ブラウザがユーザーを保護するプライバシー問題の種類についてのガイドとして、Target Privacy Threat Model があります。 この文書は執筆時点で検討中ですが、大まかな分類をいくつか示しています。 検出できます。サードパーティのリソースによるリスクは主に「望ましくないクロスサイト認識」です。 「機密情報の開示」によって、ウェブサイトは複数のサイトで同じユーザーを識別できます。 ユーザーが機密情報と見なす情報。
これは重要な違いです。望ましくないクロスサイト認識は、たとえサードパーティが追加の機密情報を収集しなくても、悪影響を及ぼします。 ユーザーが自分の ID を管理できなくなるからです。ユーザーのリファラーと IP アドレスにアクセスする Cookie はそれ自体が望ましくない開示ですサードパーティ リソースの使用には、使用方法に関する計画コンポーネントが付属しています。 プライバシーを保護する方法で保護できます。その作業には、サイト開発者が行う作業もあれば、ブラウザが行うものもあります ユーザーエージェントとしての役割です。つまり、機密情報の漏えいを防ぎ、 可能な限り望ましくないクロスサイト認識を行います。以下では、ブラウザでの緩和策とアプローチについて詳しく説明します サイト開発レベルです
サーバーサイドのサードパーティのコード
以前のサードパーティ定義では、HTTP Almanac のむしろクライアント側のアプローチ（必要に応じて）が意図的に変更されています。 第三者の著者情報を含めるようにします。プライバシーの観点から、第三者とは、何か知っている人のことです。 表示できるようになります
これには、クライアントだけでなく、サーバー上で利用するサービスを提供するサードパーティも含まれます。プライバシーから サードパーティ ライブラリ（NPM、Composer、NuGet に含まれるものなど）を理解するのも重要です。 依存関係は国境の外にデータを渡すか。ロギング サービスやリモートでホストされるデータベースにデータを渡すと、 「Phone Home」も含める場合は場合、これらはユーザーのプライバシー 監査が必要になります通常、サーバーベースのサードパーティは、ユーザーデータを渡さなければなりません。つまり、 データの制御下に置くことができます。一方、クライアント ベースのサードパーティ（スクリプトや HTTP リソース）は、 （そのプロセスを行わずに、ユーザーから直接データを収集できる） お客様によってメディエーションされる データ収集の数を管理できますこのモジュールでは、これらのクライアントサイドのサードパーティを特定する方法について取り上げます。 メディエーションをほとんど実施できないという前提でしかし その価値は サーバーサイド コードのセキュリティを考慮し、サーバーサイド コードからのアウトバウンド通信を把握し、 想定外の結果です詳細な手順の詳細はここでは取り上げません（サーバーの設定によってかなり異なります）。 これもセキュリティとプライバシーに対する取り組みの一環です。
第三者に注意が必要なのはなぜですか。
サードパーティのスクリプトや機能は非常に重要です。ウェブ デベロッパーの Google の目標は、そのようなものを統合することです。 それから目をそらさないで！ただし、潜在的な問題もあります。サードパーティのコンテンツによってパフォーマンスの問題が生じたり、 また、信頼境界内で外部サービスを取り込むことになるため、セキュリティの問題が生じます。サードパーティ コンテンツによってプライバシーの問題が生じることもあります。
ウェブ上のサードパーティのリソースについて説明する場合、セキュリティの問題は（とりわけ） サードパーティが会社からデータを盗む可能性があります。プライバシーの問題は特にそうです。 含めた第三者が、ユーザーの認証情報を盗んだり、データを保護することができます。
セキュリティの問題の例としては、「ウェブ スキマー」がクレジット・カード情報を窃取する、第三者が ユーザーがクレジット カード情報を入力するページでは、そのようなクレジット カード情報を盗み、 できます。こうしたスキマーのスクリプトを作成する人は、どこかで隠すという独創的な方法で作っています。 1 つの要約では、スキマー スクリプトが サイトのロゴ、ファビコン、ソーシャル メディア ネットワークに使用される画像など、サードパーティのコンテンツに隠れている 一般的なライブラリ（jQuery、Modernizr、Google タグ マネージャーなど）、サイト ウィジェット（ライブチャット ウィンドウなど）、CSS ファイルなどから行います。
プライバシーの問題は少し異なります。次のサードパーティもサービスに含まれます。 ユーザーの日常業務をユーザーを信頼しているという確信を持つ必要があります。使用しているサードパーティが、 データの削除や検出を困難にする、データ侵害を受けた、ユーザーのデータを侵害するなどの行為を 期待が高まっていると、ユーザーはそれを単なる商品の購入ではなく、サービスに対する信頼の崩壊として認識するでしょう。 あります。現在の評判と関係です。だからこそ、自問自答してみましょう。 サイトで使用しているサードパーティ
サードパーティの例
ここでは「サードパーティ」と実際には種類が異なり、アクセスできるユーザーデータの量も異なります。
たとえば、別のサーバーから読み込まれた HTML に <img> 要素を追加すると、そのサーバーには異なる情報が提供されます。
<iframe> や <script> 要素を追加するよりも、ユーザーについてより深く理解できます。これらはすべてを網羅したリストではなく、
サイトで使用できるサードパーティのアイテムの違いを理解するのに役立ちます。
クロスサイト リソースのリクエスト
クロスサイト リソースとは、サイト内にあるもので、別のサイトから読み込まれるもので、<iframe> や <script> ではありません。例
<img>、<audio>、<video>、CSS によって読み込まれるウェブフォント、WebGL テクスチャなどがあります。これらはすべて HTTP リクエストを介して読み込まれます。
前述のように、これらの HTTP リクエストには、そのサイトによって以前に設定されたすべての Cookie、リクエストしているユーザーの IP アドレス、
現在のページの URL を参照 URL として指定します。このデータは、過去のすべてのサードパーティ リクエストにデフォルトで含まれていましたが、
さまざまなブラウザからサードパーティに渡されるデータを削減または分離する取り組みもあります。詳しくは「
サードパーティのブラウザの保護」詳しく説明します。
クロスサイト iframe の埋め込み
<iframe> を介してページに埋め込まれたドキュメントは、3 つの要素に加えてブラウザの API への追加アクセスをリクエストできます。
Cookie、IP アドレス、参照 URL などです<iframe>d ページで使用できる API とそのアクセスのリクエスト方法はブラウザごとに異なります。
現在変更中: 「権限に関するポリシー」をご覧ください以下で、埋め込みインフラストラクチャでの API アクセスの削減またはモニタリングに関する現在の取り組みについて、
ドキュメントをご覧ください
クロスサイト JavaScript の実行
<script> 要素を含めると、ページの最上位のコンテキストでクロスサイト JavaScript が読み込まれ、実行されます。つまり、
独自のファーストパーティのスクリプトが実行するすべての内容に、完全なアクセス権が付与されます。このデータはブラウザ権限で管理されるため、
そのため、たとえばユーザーの位置情報をリクエストする場合は、やはりユーザーの同意が必要です。ただし このページ内の情報や
スクリプトで読み取ることができます。これにはサードパーティに渡される Cookie だけでなく、
サイトのみを対象とする Cookie も
リクエストの一部として含まれます同様に、サードパーティ スクリプトを
ページは、独自のコードと同じ HTTP リクエストをすべて実行できます。つまり、バックエンド API に fetch() リクエストを送信してデータを取得できます。
サードパーティ ライブラリを依存関係に含める
前述のように、サーバーサイド コードにはサードパーティの依存関係も含まれる可能性があり、これらはご自身のものと区別がつきません。 コードの記述に力を入れます。GitHub リポジトリまたはプログラミング言語のライブラリ（npm、PyPI、composer など）からインクルードするコード 他のコードと同じデータをすべて読み取ることができます。
サードパーティについて
そのためには、サードパーティ サプライヤーのリストと、そのプライバシー、データ収集、ユーザー 大きく影響しています。この理解は、トレードオフの一部になります。つまり、どれほど有用で重要か、 ユーザーにとっての負担や不便さ、不便さとのバランスが取れたサービスです。サードパーティ コンテンツを利用することで、サイト所有者の負担を軽減し、本来の業務に集中できる。 そのため、このトレードオフを行い、ある程度のユーザーの快適性とプライバシーを犠牲にして、ユーザー エクスペリエンスを向上させることに価値があります。 ただし、ユーザー エクスペリエンスをデベロッパー エクスペリエンスと混同しないようにすることが重要です。「開発チームが開発したほうが、 確認できます。説得力のあるストーリーではありません
これを理解する方法は、監査のプロセスです。
サードパーティを監査する
第三者の業務を把握するには、監査プロセスが必要です。これは技術的にも非技術的でも可能です。 個々のサードパーティまたはコレクション全体の 値を確認できます
非技術監査を実施する
最初のステップは技術的な内容ではありません。サプライヤーのプライバシー ポリシーをお読みください。サードパーティのリソースを含める場合は プライバシーポリシーを確認してください。法的文書が長くなり、ドキュメントによってはいくつかのアプローチが使われる場合があります。 以前のモジュールで、過度に一般的な表現や指示のない発言などに対して特に警告されている いつ、どのように収集データを削除するかについて、明確に規定しています。ユーザーの視点から見ると、すべてのデータを サードパーティによるものを含め、サイトで収集されるデータには、これらのプライバシー ポリシーが適用されます。仮に 目標を透明化して ユーザーの目標を上回るにはデータ プライバシーとプライバシーに対する 機密情報を扱う場合、ユーザーは、自身が選択した第三者の行動すべてに対してもユーザーが責任を負うことを義務付ける場合があります。「新規顧客の獲得」目標の 独自のポリシーに記載しない方がよいでしょう。ユーザーのプライバシー ポリシーが次に、 代替サプライヤーの有無を検討する。
これは、この後に説明する技術監査と密接に連携して活用するのに有用です。 別のものです。ビジネス上の理由で組み込む第三者のリソース（広告ネットワークなど）を把握しておくことが必要です。 埋め込みコンテンツなど）と、ビジネス上の関係が構築されるためです。このコースは、技術以外の知識の応用から 監査です。技術監査では第三者も特定される可能性が高くなります。特に、技術ではなく、 そのリストはビジネス上の理由（外部コンポーネント、分析、ユーティリティ ライブラリ）よりも優先され、 使用できるようにします。ここでの目標は、サイト所有者が、3 つ目の 法的助言を与えられるかどうかを お客様に提示できます 必要な義務をすべて果たしているかどうかを確認することが重要です。
技術監査を実施する
技術監査では、リソースをウェブサイトの一部としてその場で使用することが重要です。つまり、依存関係を読み込んで テストハーネスに入れて、そのように検査します。依存関係が実際のウェブサイトの一部としてどのように機能するかを確認します。 テストモードや開発モードではなく、公共のインターネット上にデプロイされます。自分のウェブサイトを します。ログインせずに同意書を保存せずに新しいプロファイルでブラウザを開き、サイトにアクセスします。
ユーザー アカウントを提供する場合は、独自のサイトで新しいアカウントに登録します。設計チームがこの新規ユーザーをオーケストレートします
ユーザー獲得プロセスを考慮していますが、プライバシーの観点からアプローチすると例示できる可能性があります。単にクリックするのではなく
「承諾」利用規約、Cookie に関する警告、プライバシー ポリシー。独自のサービスを使用するタスクを
個人情報を開示したりトラッキング Cookie を使用したりせずに、実行できるか、そして難しいかを確認する。
また、ブラウザのデベロッパー ツールを使用して、アクセスされているサイトや、
除外しますデベロッパー ツールには、個別の HTTP リクエストのリストが用意されており（通常は [ネットワーク] というセクションにあります）、
タイプ（HTML、CSS、画像、フォント、JavaScript、JavaScript によって開始されたリクエスト）別にグループ化されたリクエストです。また、
各リクエストのドメインを表示する新しい列を追加します。これにより、いくつもの異なるプレイスへの連絡が行われているかがわかります。
「第三者のリクエスト」が伴う可能性があります。第三者のみを表示するチェックボックスを
オンにできます（Content-Security-Policy
継続的な監査を実施するためのレポートです。これについては後述します）。
Simon Hearne の「Request Map Generator」ツールも、 サブリクエストも確認できます。
この段階で、非技術監査の一環として特定されたビジネスに特化した第三者を含めることができます。 （つまり、そのリソースを使用するために経済的な関係がある会社のリスト）。ここでの目標は、 （財務記録や法律上の記録から）利用していると思われる第三者のリストと、実際に使用しているリストを照合します。 （ウェブサイトが行ったサードパーティの HTTP リクエストを調べることで）。各ビジネスを 3 つ目に 技術的なアウトバウンド リクエストを行った当事者。第三者に対する技術監査でリクエストを特定できない場合 ビジネス関係によって特定される可能性がある場合は、その原因を突き止め、テストの指針となることが重要になります。たとえば、 特定の国、特定のデバイスタイプ、またはログイン ユーザーに対してのみリソースが読み込まれている。これにより、 監査するサイト領域のリストを作成し、すべてのアウトバウンド アクセスが表示されていることを確認します。（または、第三者プロバイダが 費用を節約でき、財務部門も常に元気づけます）。
監査を希望する第三者へのリクエストのリストを絞り込んだら、 そのリクエストの全詳細、特にそのリクエストに渡されたデータが表示されます。また、 コードによって開始されたサードパーティ リクエストが、その後に他の多くのサードパーティ リクエストを開始するというのはよくあることです。 これらの追加の第三者も「インポート」されます。独自のプライバシーポリシーに 組み込むことができますこのタスクは手間がかかりますが価値があり、 多くの場合、既存の分析に挿入できます。フロントエンド開発チームは サービスに対するリクエストの監査を パフォーマンス上の理由（おそらく WebPageTest や Lighthouse などの既存のツールを利用）や、 簡単に行えるようになります
<ph type="x-smartling-placeholder">
すべきこと
ログインせずに、保存済みの契約が残らないよう、クリーンな新しいユーザー プロファイルでブラウザを開きます。ブラウザを開いて すべての送信リクエストが表示されます。各リクエストのドメインを示す新しい列を追加して、 "第三者のリクエスト"サードパーティが存在する場合はそれだけを表示する以下の手順を行います。
- サイトにアクセスします。
- ユーザー アカウントを提供する場合は、新しいアカウントに登録します。
- 作成したアカウントを削除してみます。
- サイト上で通常の操作を 1 ～ 2 回実施します（厳密にはサイトの機能によって異なりますが、ほとんどのユーザーがよく行うアクションを選んでください）。
- 特にサードパーティの依存関係に関係することがわかっているアクションを 1 ～ 2 つ実行します。これには、 他のサイトのコンテンツの埋め込みなど、
これらの各タスクを行うときに、[ネットワーク] パネルを確認して、自分のものではないドメインからリクエストされたリソースを記録してください。 あります。これらはお客様のサードパーティの一部です。それには、ブラウザのネットワーク ツールを使用してネットワークをキャプチャし、 HAR ファイルに記述します。
HAR ファイルとキャプチャ
HAR ファイルは、ページによって行われるすべてのネットワーク リクエストの標準化された JSON 形式です。 特定のページの HAR ファイルを取得するには、次のコマンドを使用します。
Chrome
ブラウザの DevTools を開き（[メニュー] > [その他のツール] > [デベロッパー ツール]）、[Network] パネルに移動して、ページを読み込み（または更新）します。 右上の [スロットリングなし] プルダウン メニューの近くにある 下矢印セーブアイコンを選択します。
Firefox
ブラウザ デベロッパー ツールを開き（[メニュー] > [その他のツール] > [ウェブ デベロッパー ツール]）、[ネットワーク] パネルに移動してページを読み込み（または更新）して、 歯車アイコンをクリックしますメニューから [Save All As HAR**] を選択します。
![Firefox デベロッパー ツールのネットワーク パネルで [Save All As Har] オプションがハイライト表示されている。](https://web.dev/static/learn/privacy/third-parties/image/the-firefox-developer-too-1aaf7373530fd.png?hl=ja)
Safari
ブラウザのデベロッパー ツールを開きます（[メニュー] > [開発] > [ウェブ インスペクタを表示]）。[開発] メニューがない場合は、 メニュー >Safari >設定 >詳細設定 >メニューバーに [開発メニューを表示] を選択して、[Network] パネルに移動し、ページを読み込み（または更新）します。 をクリックし、右上の [エクスポート] を選択します（[ログを保持] の右側です。ウィンドウを拡大しなければならない場合があります）。
![Safari Web Inspector の [Network] パネル。HAR エクスポート オプションがハイライト表示されている。](https://web.dev/static/learn/privacy/third-parties/image/safari-web-inspector-netw-fff04392d0941.png?hl=ja)
さらに詳細として、サードパーティに渡される内容を記録することもできます（[リクエスト] セクションで確認できます）。ただし、このようなデータは多くの場合、 難読化され、解釈が困難です。
サードパーティを統合する際のベスト プラクティス
サイトで使用するサードパーティについて、独自のポリシーを設定できます。つまり、使用する広告プロバイダをそれぞれの慣行に応じて変更する。 Cookie 使用の同意ポップアップが煩わしいか煩わしいか、サイトでソーシャル メディアのボタンを使うか、 メール内のトラッキング リンク、またはツイート内の Google アナリティクスでトラッキングする utm_campaign リンク。クラウドに移行する際に考慮すべき点の一つが サイトの開発は、分析サービスのプライバシーとセキュリティ対策です。一部の分析サービスでは 考えています多くの場合、プライバシー保護を追加するサードパーティのスクリプトを使用する方法もいくつかあります。 ユーザー エクスペリエンスの向上を目指す最初のチームではありませんサードパーティ データの収集からプライバシーを保護し、 考えてみましょう最後に、多くのサードパーティ プロバイダは現在、データ収集の問題に対して以前よりも敏感になっています。 多くの場合、ユーザー保護モードを強化する機能やパラメータを追加できます。こちらの例をご覧ください。
ソーシャル メディアの共有ボタンを追加する場合
HTML ボタンを直接埋め込むことを検討してみてください。サイト https://sharingbuttons.io/ で、適切に設計されたサンプルがいくつか提供されています。 または、HTML リンクを追加することもできます。この場合のトレードオフは「共有数」が顧客を分類して 確認できます。これは、サードパーティ プロバイダを利用することと、受け取る分析データが少なくなるトレードオフの例です。
より一般的には、サードパーティからある種のインタラクティブなウィジェットを埋め込む場合、多くの場合、代わりに その第三者にリンクできますつまり、サイトにインライン エクスペリエンスはありませんが、共有に関する意思決定が変わります。 サードパーティとデータを共有するかどうかを選択できます。
たとえば、以下のように Twitter と Facebook のリンクを追加し、estimate.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!&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 という API を
動画や埋め込みコンテンツへのリンクを指定すると、サムネイルやタイトルなど、動画に関するプログラム上の詳細情報が返されます。TikTok は oEmbed をサポート
（詳しくは https://developers.tiktok.com/doc/embed-videos をご覧ください）。つまり、
TikTok 動画へのリンク https://www.tiktok.com/@scout2015/video/6718335390845095173 を、（手動またはプログラムで）その動画に関する JSON メタデータに変換できます。
https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 になるため、サムネイルを取得する
表示されます。WordPress はこれを使用して oEmbed をリクエストすることが多い埋め込みコンテンツの情報などです。これをプログラムで使用するには、
「ファサード」をインタラクティブな動画を作成し、ユーザーがクリックするとインタラクティブな動画を埋め込むか、その動画へのリンクに切り替わります。
分析スクリプトを埋め込む場合
アナリティクスは、ユーザーに関する情報を収集して分析するように設計されています。分析システムは基本的に アクセスとユーザーに関するデータを収集して表示するサービス。Google アナリティクスなどの第三者サーバー上で行われ、 説明します。https://matomo.org/ のような自己ホスト型の分析システムもありますが、 サードパーティソリューションも 利用していますこのようなシステムを独自のインフラストラクチャで実行すると、データの収集は削減できますが、 自社のエコシステムから離れないからですその一方で、データの管理や削除、ポリシーの設定には、 お客様の責任となります。クロスサイト トラッキングに関する懸念の多くは、密かに行われ、 密かに行う、またはデータ収集がまったく必要ないサービスを使用する際の副作用として発生する可能性がある。分析ソフトウェアは サイト所有者にユーザーに関する情報を通知する目的でデータを収集するように設計されています。
大きな漁網や 後で分析して、興味深いパターンを見つけます。このマインドセットは主に、不安と不安感を生み出した データ収集について学びました多くのサイトはまず どの質問をすればよいかを考え その問いに答えるために、具体的かつ限定的なデータを収集します。
自分のサイトや他のサイトでサードパーティのサービスを使用していて、そのサービスの JavaScript をサイトに組み込むことで機能する場合は、 ユーザーごとに Cookie を設定します。この場合、ユーザーが望ましくないクロスサイト認識を行っている可能性があります。 サイトをまたいでユーザーをトラッキングする場合ですそうでない場合もあれば、そうでない場合もありますが、ここでのプライバシー保護のスタンスは、 正当な理由がない限り、このようなサードパーティ サービスは実際にはクロスサイト トラッキングを行っています。 これ自体はそのようなサービスを避ける理由ではありませんが、トレードオフを評価する際に考慮する必要があります いくつかあります。
かつて分析におけるトレードオフは、それを使用するかどうかの選択のみであり、その引き換えにすべてのデータを収集し、プライバシーを侵害することしかありませんでした。 分析情報や計画に使用することはできませんしかし現在は状況が変わってきており 両者の中間に位置します制限の設定オプションについては、分析プロバイダにお問い合わせください。 保存されるデータの量と保存期間を短縮できます。技術監査のレコードがあるので その監査の関連セクションを再実行して、これらの構成の変更が影響することを確認できます。 収集するデータの量を減らすことです既存のサイトでこの移行を行う場合は、 ユーザーのために記述できる定量化可能な尺度たとえば、Google アナリティクスにはオプトイン（デフォルトで無効）の機能があります。 プライバシーに関する機能があり、その多くは現地のデータ保護法の遵守に役立つ可能性があります。Google Workspace を設定する際に考慮すべきいくつかの アナリティクスでは、収集したデータの保持期間（[管理] > [トラッキング情報] > [データ保持]）をデフォルトの 26 か月よりも短く設定する。 また、部分的な IP 匿名化などの技術的ソリューションも有効にします（詳しくは、https://support.google.com/analytics/answer/9019185 をご覧ください）。
プライバシーを保護する方法でのサードパーティの使用
ここまで、アプリケーションの設計段階でユーザーをサードパーティから保護する方法を説明しましたが、 そのアプリケーションで何を行うかを計画します特定のサードパーティを一切使用しないという 計画もあります 使用の監査もこのカテゴリに分類されます。プライバシーの姿勢に関する意思決定を行うことを意味します。ただし、 決定は本質的にあまり詳細ではありません。特定のサードパーティを利用するかどうかの選択は、微妙な判断ではありません。 その中間で何かを求める可能性が高いでしょう プライバシー侵害の傾向（意図的か偶発的かを問わない）の軽減。タスクは、「ビルド時」にユーザーを保護するものです。 予期せぬ被害を低減するために安全保護対策を追加する。これらはすべて新しい HTTP ヘッダーで、HTTP ヘッダーを 特定のプライバシーまたはセキュリティ上のスタンスを取るようユーザー エージェントに指示する、または指示するページです。
参照 URL ポリシー
すべきこと
他のサイトがリファラー ヘッダーを受信しないようにするには、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 リクエストは、リクエストを開始したページの URL を含む Referer ヘッダーを渡します。
リンク、埋め込み画像、スクリプトなどです。URL には個人情報が含まれていることがあり、その URL には個人情報が含まれている可能性があるため、プライバシーの問題が発生する可能性があります。
その個人情報が第三者に渡されることになります。Web.dev でいくつか例が紹介されている
プライベート データを含む URL の数（https://social.example.com/user/me@example.com からサイトにアクセスしたユーザー）から、そのユーザーが誰であるかがわかります。
明らかに漏えいしていますしかし、URL そのものに個人情報が含まれない URL であっても、その特定のユーザー（ご存じかもしれませんが、
ユーザーがログインしている場合など）は、別のサイトからここにアクセスしていたため、このユーザーがそのサイトにアクセスしたことがわかります。これ自体が
ユーザーの閲覧履歴について知るべきでない情報もあります。
正しい表記の Referrer-Policy ヘッダーを指定すると、参照 URL の一部または全部を渡さないように変更できます。
MDN には詳細情報が表示されますが、ほとんどのブラウザでは
デフォルトで strict-origin-when-cross-origin の値が想定されるようになりました。つまり、参照 URL が第 3 の
配信元としてのみ指定できます（https://web.dev/learn/privacy ではなく https://web.dev）。これは有用なプライバシー保護であり、
何もする必要はありません。ただし、Referrer-Policy: same-origin を指定して何も渡さないようにすることで、これをさらに強化できます。
リファラー情報を第三者に一切渡さないようにする（自身の送信元を含む第三者には渡さないように Referrer-Policy: no-referrer）。
（これはプライバシーとユーティリティのバランスの好例です。新しいデフォルト設定では、以前よりもプライバシー保護が強化されていますが、
その場合でも、選択した第三者（分析プロバイダなど）には概要情報が提供されます）。
また、このヘッダーを明示的に指定すると、ブラウザのデフォルト設定に依存することなく、ポリシーを正確に把握できるため便利です。
ヘッダーを設定できない場合は、<head> でメタ要素を使用して、HTML ページ全体にリファラー ポリシーを設定できます。
<meta name="referrer" content="same-origin">、特定のサードパーティについて懸念がある場合は、referrerpolicy を設定することもできます。
個々の要素（<script>、<a>、<iframe> など）での属性: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">
Content-Security-Policy
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 を追加します。
JSON がその URL に送信されたら、それを保存します。保存されたデータを確認して、あなたのウェブサイトが他の人のアクセス時に要求したサードパーティ ドメインのコレクションを取得します。
必要なドメインをリストするように 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=*
この例では、このページ（「self」）とオリジン example.com の <iframe> で navigator.geolocation API を使用できます。
JavaScript から生成できますこのページとすべてのサブフレームでフルスクリーン API を使用でき、このページを含むどのページも禁止します。
カメラを使用して動画情報を読み取ることはできません。詳細と考えられる例の一覧をご覧ください。
Permissions-Policy ヘッダーで処理される機能のリストは膨大であり、流動的である可能性があります。現在、このリストは https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md にある
すべきこと
Permissions-Policy に対応しているブラウザでは、デフォルトでサブフレームの高度な機能が許可されていないため、有効にする必要があります。
このアプローチはデフォルトでは非公開です。サイト上のサブフレームにこうした許可が必要な場合は、選択して追加できます。
ただし、デフォルトではメインページに適用される権限ポリシーはないため、
機能の使用は制限されません。このため、制限付きの API の使用を
デフォルトですべてのページに 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=()
ウェブブラウザに組み込まれているプライバシー機能について
「ビルド時間」と「Design time」を保護に加えて、「実行時に」発生するプライバシー保護もあります。 ユーザーを保護するためにブラウザ自体に実装されている機能。直接操作したり、サイトとして利用したりできる機能ではありません これらはサービスの機能ですが、サイトがサービスの決定の影響を受ける可能性があるため、知っておくべき機能です。 表示されます。待機するクライアントサイドの JavaScript がある場合に、こうしたブラウザ保護がサイトに及ぼす影響の例 サードパーティ依存関係が読み込まれてからページ設定を続行できず、サードパーティの依存関係がまったく読み込まれない場合、ページ設定 完了しない可能性があるため、ユーザーにはページが半分ずつ表示されます。
Safari にはインテリジェント トラッキング防止機能が含まれています。 （および基盤となる WebKit エンジン）、Enhanced Tracking Protection （およびそのエンジンの Gecko）です。これらはすべて、サードパーティがユーザーの詳細プロフィールを作成するのを困難にしています。
プライバシー機能に対するブラウザでのアプローチは頻繁に変更されるため、常に最新の情報を維持することが重要です。次の保護機能のリストと
本稿の執筆時点では正しい情報ですブラウザには、他の保護機能が実装されている場合もあります。なお、このリストはすべてを網羅しているわけではありません。ベスト プラクティスに関するモジュールを確認する
をご覧ください。また、今後のブラウザのバージョンで、プロジェクトに影響する可能性のある変更がないか必ずテストしてください。
シークレット モードまたはシークレット ブラウジング モードでは、ブラウザのデフォルト設定とは異なる設定が適用される場合があります（サードパーティ Cookie がブロックされることがあります）。
デフォルトで暗号化されます。したがって、次のような場合は、シークレット モードでのテストが、ほとんどのユーザーの一般的なブラウジング エクスペリエンスを反映していない場合があります。
シークレット ブラウジングを使用していない。また、さまざまな状況で Cookie をブロックすると、window.localStorage、
ブロックされています。
Chrome
- サードパーティ Cookie は、今後ブロックされる予定です。本ガイドの執筆時点では、これらのログはデフォルトでブロックされません。 （ユーザーが有効にすることもできます）。https://support.google.com/chrome/answer/95647 で詳しく解説します。
- Chrome のプライバシー機能、特に Google やサードパーティのサービスと通信する Chrome の機能。 privacysandbox.com/ をご覧ください。
Edge
- サードパーティ Cookie はデフォルトではブロックされません（ユーザーが有効にすることもできます）。
- Edge のトラッキング防止機能によるブロック 未アクセスのサイトからのトラッカーや既知の有害なトラッカーはデフォルトでブロックされます。
Firefox
- サードパーティ Cookie はデフォルトではブロックされません（ユーザーが有効にすることもできます）。
- Firefox のトラッキング防止機能は、デフォルトでトラッキング Cookie をブロックします。 フィンガープリントスクリプト、クリプトマイナースクリプト、既知のトラッカーの使用。(https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track で詳細を確認できます）。
- サードパーティ Cookie にはサイトの制限があるため、基本的に各サイトに個別の Cookie ジャーが割り当てられており、サイト間で Cookie を関連付けることはできません。 サイト（Mozilla ではこれを「Total Cookie Protection」と呼んでいます）。
何がブロックされているかを調べたり、問題をデバッグしたりするには、アドレスバーの盾のアイコンをクリックするか、Firefox（パソコン版）で about:protections にアクセスしてください。
Safari
- サードパーティ Cookie はデフォルトでブロックされています。
- インテリジェント トラッキング防止機能の一環として、
Safari は、他のページに渡されるリファラーを、特定のページではなくトップレベル サイトに減らします（
https://something.example.com、 （https://something.example.com/this/specific/pageではなく）。 - ブラウザの
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 が必要な理由
ブラウザ サービスの新しいプライバシー保護機能とポリシーは、ユーザーのプライバシー保護に役立ちますが、課題も伴います。 多くのウェブ テクノロジーは、他の目的で使用されている場合でも、クロスサイト トラッキングに使用できます。たとえば 私たちが毎日使用している多くの ID 連携システムがサードパーティ Cookie に依存しています。さまざまな広告ソリューションで 多くの企業がサードパーティ Cookie を基盤としています。多くの不正行為検出ソリューションはフィンガープリントに依存しています。内容 どのようなことが起こるのでしょうか
ブラウザがユースケースを区別し、プライバシーを侵害する用途を確実に区別するのは困難であり、エラーが発生しやすい できます。これが、ユーザーを保護するためにサードパーティ Cookie とフィンガープリントをブロックするか、そうするつもりです。 プライバシーを保護する。
新しいアプローチが必要: サードパーティ Cookie が段階的に廃止され、フィンガープリントが軽減されるにつれ、開発者には専用開発の API が必要 ユースケースに合致するものの、プライバシーに配慮した設計になっている。設計と構築が目的です。 クロスサイト トラッキングに使用できない API。前のセクションで説明したブラウザの機能とは異なり、 クロスブラウザ API を目指しています。
API 提案の例
以下のリストはすべてを網羅しているわけではなく、これから取り上げる内容の一部にすぎません。
サードパーティ Cookie を基盤とする技術に代わる API 提案の例:
- ID のユースケース: FedCM
- 広告のユースケース: プライベート クリック測定、 相互運用可能なプライベート アトリビューション、 Attribution Reporting、Topics、 FLEDGE、PARAKEET。
パッシブなトラッキング技術を代替する API 提案の例：
- 不正行為検出のユースケース: Trust Token。
サードパーティ Cookie を使わずに将来的に他の API が構築できる提案の例:
さらに、これまでのブラウザ固有の隠れたトラッキングの軽減を試みる別のタイプの API が登場しています。 その一例がプライバシー バジェットです。さまざまな Chrome が当初提案していた API は、プライバシー サンドボックスという包括的用語のもとで提供されています。
Global-Privacy-Control は、ユーザーが が、収集した個人データが他のサイトと共有されないようにしたいと考えています。その意図は、廃止された「Do Not Track」と似ています。
API 提案のステータス
これらの API 提案のほとんどは、まだデプロイされていないか、テストのためにフラグの背後または限られた環境にのみデプロイされています。
この公開の検討フェーズは重要です。ブラウザ ベンダーとデベロッパーは、これらの API が問題ないかどうかについての議論と経験を集めます。 本当に目的を果たすかどうかですデベロッパー、ブラウザ ベンダー、その他のエコシステム関係者がこのフェーズを使用する API の設計を反復処理できます
現在提案されている新しい API についての最新情報は、GitHub にある Privacy Group の提案リストをご覧ください。
これらの API を使用する必要性
サードパーティ Cookie やフィンガープリントなどの手法を基にプロダクトを直接構築している場合は、これらの新しい API に参加してテストし、ディスカッションや API 設計に独自の経験を貢献してください。 それ以外の場合、本稿の執筆時点でこれらの新しい API の詳細をすべて理解している必要はありませんが、今後リリースされる API について知っておくと良いでしょう。