ナビゲーションをスキップ
部 II 章 10

プライバシー

公開日：
Web Almanacのキャラクターたちがカメラや電話、マイクを持ってパパラッチのように振る舞い、別のキャラクターがシャワーカーテンを開けて背後にあるウェブページを見せているヒーロー画像。
Yash Vekaria、 Benjamin Standaert、 Max Ostapenko、 Abdul Haddi Amjad、 Yana Dimova、 Shaoor Munir、 Chris Böttger と Umar Iqbal によって書かれた。
Alberto Fernandez-de-Retana によってレビュ。
Max Ostapenko、 Yash Vekaria、 Benjamin Standaert と Abdul Haddi Amjad による分析。
Barry Pollard 編集。
Sakae Kotaro によって翻訳された。

はじめに

ユーザーはウェブを閲覧する際に、重大なプライバシー問題に直面します。たとえば、ユーザーが訪問するほとんどのウェブサイトには、ユーザーの活動を監視しプロファイリングする トラッカー が含まれています。プロファイリングされたユーザーの活動は、ターゲットを絞ったパーソナライズドオンライン広告やユーザーデータの直接販売など、プライバシーを侵害するさまざまな目的で利用されます。

トラッカーは、Cookie（ファーストパーティとサードパーティの両方）、ブラウザフィンガープリント、個人を特定できる情報（メールアドレスなど）の使用など、ウェブ上でユーザーを追跡するために幅広い技術を展開しています。

プライバシーを保護するため、ユーザーは広告ブロッカーやトラッカーブロッカーのようなプライバシー強化ツールに頼っています。これらのツールはウェブページへのオンライントラッカーの読み込みを阻止します。同様に、ブラウザはサードパーティCookieのブロックなど、設計によっていくつかのプライバシー問題を排除することを目的としたプライバシー保護機能を導入しています。

残念ながら、トラッカーはプライバシー強化技術との競争を繰り広げており、ブラウザのプライバシー保護を回避するメカニズムを継続的に模索しています。最近ではバウンストラッキングやCNAMEトラッキングがそれに当たります。ここ数年、政府はカリフォルニア州のCCPAやEUのGDPRといったデータ保護規制に介入し、ユーザーがデータ収集に同意しないなどの権利を行使できる仕組みを提供しています。

この章では、オンライン追跡の概要を説明します。これには、Cookieやブラウザフィンガープリントなどの追跡メカニズムが含まれます。さらに、ブラウザが提供するプライバシー保護、トラッカーが悪用する回避技術、データ保護規則の下で提供される保護の導入についても概説します。

オンライントラッキング

ページごとのトラッカーの分布。
図10.1. ページごとのトラッカーの分布。

私たちは主に、WhoTracks.Meのデータを活用しています。これは、さまざまなウェブサイトに存在するサードパーティトラッカーをカタログ化した公開リストです。このリソースを利用して、ウェブサイト上で、もっとも普及しているトラッカーを特定しました。これにより、特定のトラッキング企業の優位性を評価しサードパーティトラッキングの全体像をより深く理解できました。WhoTracks.Meはドメインレベルでいくつかのトラッカーを識別するため、注意が必要です。これらのドメインに関連付けられたURLの多くはトラッキングを行っていますが、そのドメインのすべてのURLがそうであるとは限りません。

オンライントラッキングは、インターネット上で日常的に行われています。多くのウェブサイトには、自サイト内や複数のサイトにわたってユーザーの活動を記録する、専門のオンラインサービスが含まれています。私たちの調査から、デスクトップウェブサイトの95％とモバイルウェブサイトの94％に、少なくとも1つのトラッカーが含まれていることが明らかになりました。

また、デスクトップサイトの27％、モバイルサイトの26％と、いずれも4分の1以上が10個以上のトラッカーを含んでいることも注目されます。これらのトラッカーにより、企業はオンライン行動に基づいた詳細なユーザープロファイルを作成できます。これはパーソナライズ広告やウェブサイト所有者へのインサイト提供に定期的に利用されます。以降のセクションでは、トラッカーがユーザーの活動を監視するために用いるさまざまな技術と、最新ブラウザが導入したプライバシー保護をいかにして回避しようとしているのかを探ります。

ステートフルな追跡

オンライントラッキングは、ステートフル追跡とステートレス追跡の2つに大別されます。ステートフル追跡は、ユーザーに関する情報をユーザーのデバイスに直接保存するものです。通常はCookieを介して行われますが、セッションをまたいで持続するローカルストレージのような、他のストレージメカニズムも利用されます。

ユーザーがこのようなトラッカーの埋め込まれたウェブサイトを訪問すると、トラッカーに関連するCookieが自動的にネットワークリクエストに含まれます。これにより、複数のウェブサイトに埋め込まれたトラッキングサービスは、ユーザーが訪問したすべてのウェブサイトを監視できるのです。

サードパーティのトラッキングサービス

以下の図は、オンライントラッキングドメインの普及率の分布を示したものです。

WhoTracksMeのトップトラッカー。
図10.2. WhoTracksMeのトップトラッカー。

Googleが所有するドメインがトラッキング業界を席巻しており、googleapis.comとGoogleのgstatic.comがそれぞれ68％と61％と、もっとも高い割合のページに表示されていることがわかります。その他の著名なトラッカーには、Google TagとGoogle Analyticsがあり、それぞれ50％以上のページで見られ、Googleのトラッキングサービスの広範なリーチを浮き彫りにしています。Googleとその関連サービスに加えて、FacebookとCloudflareの顕著な存在も確認できます。

サードパーティCookie
サードパーティCookieのトップオリジン。
図10.3. サードパーティCookieのトップオリジン。

サードパーティCookieは、ウェブ上でユーザーを追跡するために使用される主要なメカニズムです。私たちの測定では、Googleのdoubleclick.comがサードパーティCookieの最大のソースであり、クロールされたウェブページの4分の1以上に存在することが明らかになりました。2022年の分析と比較して、サードパーティCookieのトップソースはほぼ静的なままであり、以前は2番目に大きなサードパーティCookieのソースであったFacebookが著しく欠けています。しかし、次のセクションで示すように、代わりにファーストパーティのコンテキストでFacebookによって設定された多数のCookieが見られます。

サードパーティCookieのトップネーム。
図10.4. サードパーティCookieのトップネーム。

多くのドメインでCookieを共有するトラッカーを特定するため、サードパーティCookieのもっとも一般的な名前も調査します。Googleのドキュメントに記載されているように、上位4つのCookie名はGoogleの広告製品とYouTubeによって設定されたCookieに対応しており、5番目によくある名前はCloudflareによって設定されたCookieに対応していることがわかります。 CloudflareのCookie __cf_bm は、「自動化されたトラフィックを特定して軽減するために」使用されます。このCookieはCloudflareの個々の顧客のドメインで設定されるため、Cookieのドメインごとのランキングには含まれません。

ファーストパーティCookie
ファーストパーティCookieのトップネーム。
図10.5. ファーストパーティCookieのトップネーム。

一般的なファーストパーティCookieを測定すると、分析および広告サービスがファーストパーティのコンテキストでCookieを設定している広範な証拠が見られます。上位2つのCookie、_gaと_gidは、どちらもGoogle Analyticsの一部です。

次のCookie _fbp は、Metaによって設定されるトラッキングCookieです。2022年以降、MetaのCookieトラッキングは主にサードパーティのコンテキストからファーストパーティのコンテキストに移行したようです。Meta Pixelのデフォルト設定では、ファーストパーティCookieが設定されるようになりました。

残りのCookieの大部分は、Googleのドキュメントに記載されているように、Googleが設定したCookieと一致します。ファーストパーティCookieは、単一サイトでのアクティビティ追跡またはクロスサイト追跡のいずれかに使用できます。これらのCookieの正確な目的を特定しようとはしません。上位のCookie名のうち、PHPSESSIDとXSRF-TOKENの2つだけが、明確な非追跡目的を持っています。PHPSESSIDはPHPフレームワークがユーザーのセッションIDを保存するために使用するデフォルトのCookie名で、XSRF-TOKENはAngularフレームワークが使用するデフォルト名です。

Cookiesの章では、Cookieの詳細と使用傾向についてさらに詳しく説明しています。

ステートレス追跡

ステートフル追跡では識別子がブラウザに保存されるのに対し、ステートレス追跡では識別子が実行時に生成されます。これらの識別子は、ユーザーのデバイスやブラウザのユニークな特性に依存することがよくあります。この方法はステートフル追跡よりも信頼性が低いかもしれませんが、通常は識別とブロックがより困難です。

ブラウザフィンガープリント

ブラウザフィンガープリントは、もっとも一般的なステートレス追跡技術の1つです。ブラウザフィンガープリントを実施するために、トラッカーはJavaScript API（たとえば、Canvas）やHTTPヘッダー（たとえば、User-Agent）を介してブラウザが公開するデバイス構成情報を利用します。

ブラウザがCookieに課す制限を拡大し続けるにつれて、フィンガープリントは魅力的な代替手段となっています。先行研究では、フィンガープリントが現在一般的であり、その普及率が高まっていることがわかっています。ここでは、ウェブ全体でもっとも一般的なフィンガープリントのソースを特定しようと試みます。

私たちの分析では、まず有名なフィンガープリントライブラリの存在を調べました。テストしたライブラリの中で、ウェブ上でフィンガープリントを実行するために使用されるもっとも普及しているライブラリはFingerprintJS（FingerprintJS）であり、全ウェブサイトの0.57％で見つかりました。これは、このライブラリがオープンソースであり、無料版があるためである可能性が高いです。2022年の測定値と比較すると、これらのフィンガープリントライブラリの使用はわずかに減少していますが、今年は約400万ページものウェブページをクロールしていることに注意することが重要です。

フィンガープリントの使用状況。
図10.6. フィンガープリントの使用状況。

私たちは有名なフィンガープリントベンダーの普及率を検出しましたが、フィンガープリントに関与する可能性のある他のいくつかのサービス（ファーストパーティスクリプトを含む）があります。フィンガープリントの潜在的なソースを特定するために、まず一般的に使用されているフィンガープリントライブラリであるFingerprintJSのソースコードを調べます。次に、ライブラリが使用するAPIのリストをコンパイルし、クロールされたすべてのスクリプトでこれらのAPIの出現を検索します。5つ以上の使用箇所があるスクリプトを 潜在的な フィンガープリントスクリプトとしてマークします。次に、読み込まれるページ数でスクリプトをランク付けします。

フィンガープリントAPIの使用箇所があるトップスクリプト。
図10.7. フィンガープリントAPIの使用箇所があるトップスクリプト。

追跡に主に使用されるスクリプトと、追跡以外の目的も持つスクリプトが混在していることがわかります。もっとも一般的なスクリプトであるRecaptchaは、フィンガープリントを使用して人間とボットを区別することが知られています。Google広告とYandex Metrikaも主に追跡スクリプトです。ただし、Google Maps APIやYoutube埋め込みAPIなどの他のスクリプトには、追跡以外の目的もあるため、これらのAPIの使用はフィンガープリント以外の目的がある可能性があります。これらのスクリプトが実際にフィンガープリントを実行しているかどうかを確認するには、さらに手動で分析する必要があります。

トラッキング保護の回避

Cookieによるサードパーティのブロックなど、トラッキング保護がウェブブラウザで一般的になるにつれて、トラッカーはそれらを回避するメカニズムをますます探求しています。これらの方法は、ブラウザの機能とDNS構成を悪用し、プライバシー対策がより厳格になっても永続的なトラッキングを可能にします。

私たちは、CNAMEトラッキングとバウンストラッキングという2つの著名なトラッキング保護回避慣行を調査し、これらがウェブ上でどの程度普及しているか、またブラウザがこれらを減らし、デフォルトでユーザーのプライバシーを維持しようとしているかを調べました。

CNAMEクローキング

CNAMEクローキングは、DNS CNAMEレコードを利用して、サードパーティのトラッカーをファーストパーティのエンティティとして偽装します。CNAMEレコードを使用すると、サブドメインを別のドメインにポイントできます。トラッカーは、埋め込まれているウェブサイトのサブドメインにCNAMEレコードを設定することでこれを利用します。たとえば、tracker.example.comはtracker.trackingcompany.comを指すことができます。トラッカーがCookieを設定すると、それはexample.comから発信されたように見え、事実上ファーストパーティCookieとなり、多くのサードパーティCookieブロッキングメカニズムを回避します。この戦術はとくに効果的です。なぜなら、ほとんどのトラッキング保護対策はサードパーティのアクセスを制限することに集中しているのに対し、ファーストパーティCookieは通常、不可欠なウェブサイト機能のために許可されているからです。

DNSデータの分析では、ウェブサイトのプライマリドメインから発信され、サードパーティドメインを指すリクエストで使用されるCNAMEレコードを特定します。CNAMEレコードは、CDNなどのホスティングサービスによって正当に使用されることがありますが、トラッキングにも悪用される可能性があります。トラッキング固有の使用法に焦点を当てるために、特定されたドメインをAdGuardトラッカーリストと相互参照し、WhoTracks.Meのデータを使用して、主にホスティング関連のドメインを除外しました。

2022年のCNAMEクローキングの分析は、ファーストパーティのホスト名をAdGuardの偽装CNAMEホスト名リストにマッピングすることに依存していました。今年の分析では、特定のページから発信された各要求ホスト名の実際のDNSレコードを収集するという大幅な機能強化が組み込まれています。この直接DNS解決により、サードパーティドメインにリダイレクトするCNAMEレコードを持つホスト名を正確に特定でき、CNAMEクローキング活動のより正確で包括的なビューを提供します。この改善された方法論により、これまで文書化されていなかったutiq.com、truedata.co、actioniq.comなどに関連するトラッカーを特定し、これらをAdGuardリストにフィードバックできました。

トップ10のCNAMEクローキングドメイン。
図10.8. トップ10のCNAMEクローキングドメイン。

2024年のWeb Almanacデータは、CNAMEクローキングの継続的な傾向を明らかにしており、Adobe Analyticsに関連するomtrdc.netとadobedc.netが、それぞれモバイルページの0.031%（約9,000）と0.015%（約4,500）以上で表示され、サイト分析カテゴリをリードしています。

分析関連ドメインの普及は、CNAMEクローキングが広告だけに限定されず、より広範なデータ収集目的にも利用されていることを示唆しています。actionsoftware.comやその他の広告関連ドメインの存在は、この技術がターゲット広告に利用されていることをさらに裏付けています。

データは、CNAME全体の利用率は従来の追跡方法に比べて比較的低いものの、トラフィックの多いウェブサイトに集中しているため、多くのユーザーにとって重大なプライバシー上の懸念となっていることを浮き彫りにしています。

バウンストラッキング

バウンストラッキングは、トラッカーがファーストパーティのコンテキストからCookieを読み取ることを可能にする、もう1つの高度な回避技術です。より具体的には、バウンストラッキングはブラウザを騙してトラッキングドメインをファーストパーティサイトとして訪問させ、ファーストパーティストレージからCookieを読み書きできるようにします。トラッキングサーバーと直接通信する代わりに、ブラウザはまず中間ドメイン、つまり「バウンス」ドメイン（デモ）にリダイレクトされます。したがって、サードパーティのCookieがブロックされている場合、トラッカーはファーストパーティストレージから永続的な識別子を読み取ることができます。この中間ドメインは、実際のウェブサイトにリダイレクトします。

このナビゲーションパターンは、フェデレーション認証（たとえば、OAuth）などの機能的なパターンに似ているため、バウンストラッキングのブロックは困難です。しかし、Chrome（サードパーティCookieのブロックをオプトインした場合）、Safari、Brave、Firefoxなどのウェブブラウザは、バウンストラッキングに対する緩和策を展開しているか、展開中です。

クロールの性質が限られており、特定のページセットの読み込みに限定されているため、リダイレクトの分析は、別のページに移動した後に元のページに戻るもののみを対象としました。バウンストラッキングは、ユーザーを元のページに戻す前にファーストパーティCookieを設定するサードパーティトラッカーへの瞬間的なリダイレクトを検出することによって識別します。

トップ10のステートフルバウンスドメイン。
図10.9. トップ10のステートフルバウンスドメイン。

medium.com（モバイル0.009%または1,515ページ、デスクトップ0.013%または1,641ページで利用可能）とindapass.hu（IndaMedia）（モバイルページ0.012%または1,991ページ）がバウンストラッキングのようなナビゲーションでもっとも多く表示されることに注目します。これらの企業は、バウンストラッキングを使用して訪問者のグローバルなアイデンティティを管理し、訪問回数をカウントしてサービスを改善しています（MediumとIndaMediaは両方とも出版社です）。

クロール可能なページに限定された私たちの分析は網羅的ではなく、特定されたすべてのドメインが必ずしもプライバシーを侵害する行動を示すわけではありません。SSO（たとえば、login.taobao.com）や決済ソリューションなどの正当な使用は、バウンスドメインでのユーザー操作の有無によってトラッキングと区別できることがよくあります。

プライバシーを向上させるブラウザのポリシー

広告やソーシャルメディアプラットフォームなど、サードパーティサービスのコンテンツをウェブサイトに含めるのは一般的な慣行です。残念ながら、サードパーティサービスは暗黙のうちに信頼できるものではなく、多くの場合、ユーザーのプライバシーを直接害します。たとえば、サードパーティの追跡サービスを含めることによってです。サードパーティの章で、より詳細な分析をご覧ください。

最近、ウェブ標準化団体やブラウザベンダーは、ウェブサイト開発者がサードパーティサービスによってもたらされるプライバシーの脅威を軽減するために使用できる多くのコントロールを提供しようと介入してきました。私たちは、そのような著名なブラウザ提供のコントロールの普及率を分析します。Permissions Policyなど一部のブラウザポリシーは、セキュリティとプライバシーの両方に影響を及ぼすことに注意してください。このようなポリシーについては、セキュリティの章で説明します。

User-Agent Client Hints

とくにUser-Agent文字列を介して、ブラウジング環境について公開される情報量を最小限に抑えるための取り組みとして、User-Agent Client Hintsメカニズムがブラウザと標準化団体によって導入されています。

重要な考え方は、ユーザーのブラウジング環境に関する特定の高エントロピー情報にアクセスしたいウェブサイトは、最初の応答でヘッダー（Accept-CH）を設定する必要があるということです。

Client Hintsを使用しているページの割合。
図10.10. Client Hintsを使用しているページの割合。

上位1,000のモバイルウェブサイトの15.8%、上位10,000のモバイルウェブサイトの5.1%で展開されていることに注目します。2022年の章の結果（上位1,000：9.11%、上位10,000：3.12%）と比較して、Accept-CHヘッダーで応答するサイトの採用を見ると、人気のある1,000サイトで6.69%の採用増加が見られます。この採用の増加は、ChromiumがUser-Agent文字列で共有される情報を（User-Agent削減計画を通じて）削減しているという事実に関連していると推測されます。すべてのウェブサイトについて、Accept-CHは、デスクトップとモバイルのすべてのクロールされたウェブサイトのそれぞれ0.4%と0.5%で展開されています。

Referrerポリシー

デフォルトでは、ほとんどのユーザーエージェントにRefererヘッダーが含まれており、リクエストの送信元となったウェブサイト、あるいは特定のページをサードパーティに公開します。これは、ウェブページに埋め込まれたリソースや、ユーザーがリンクをクリックして発生したリクエストで起こります。その結果、サードパーティは特定のユーザーがどのウェブサイトやページを訪問していたかを知ることができ、プライバシー上の懸念につながる可能性があります。

Referrer Policyの実装。
図10.11. Referrer Policyの実装。

Referrer Policyを利用することで、ウェブサイトはReferrerヘッダーがリクエストに含まれるインスタンスを制限し、ユーザーのプライバシーを向上させることができます。

Referrer Policyは、ドキュメントレベルとリクエストレベルの両方で含めることができます。Referrer Policyは、デスクトップウェブページの33.87%、モバイルウェブページの32%で展開されていることがわかりました。そのようなページの21.82%では、Referrer Policyはref=noreferer HTMLタグを使用してリクエストレベルで展開されており、11.31%のインスタンスでは、Referrer Policyはドキュメントレベルで展開されています。

もっとも一般的なReferrer Policyの値。
図10.12. もっとも一般的なReferrer Policyの値。

Referrer Policyは一部の追跡を軽減できますが、すべてのオプションが同じ効果を持つわけではありません。そこで次に、個々のReferrer Policyオプションの展開を測定します。

私たちの分析によると、strict-origin-when-cross-originがReferrer Policyでもっとも一般的に使用されているオプションであり、クロールされたウェブページの8%で展開されています。また、2022年の章でクロールされたウェブページのわずか2.68%でしか展開されていなかったのと比較して、その展開がほぼ3倍に増加したことにも注目します。

strict-origin-when-cross-originは、ポリシーが指定されていない場合のデフォルトオプションでもあり、refererヘッダーの完全なURLを同一オリジンリクエストにのみ共有します。クロスオリジンリクエストの場合、パスとクエリ文字列パラメータは削除されます。

次に一般的に展開されているオプションはno-referrer-when-downgradeで、これはダウングレードリクエスト、つまりHTTPS対応ページで開始されたHTTPリクエストでRefererヘッダーを含めません。残念ながら、これでもほとんどのシナリオ、つまりHTTPS対応リクエストでユーザーが訪問しているページが漏洩します。

プライバシー関連のオリジントライアル

オリジントライアルにより、ウェブサイト開発者は新しいブラウザAPIなど、ウェブブラウザ（ChromeまたはFirefox）がリリースした新機能をテストできます。ウェブサイト開発者がオリジントライアルに登録すると、新しいブラウザ機能がすべてのユーザーに利用可能になります。ウェブブラウザはサードパーティのCookieを排除するなど、プライバシーを強化する機能をますます展開しているため、次にウェブサイト開発者がプライバシー関連のオリジントライアルに参加しているかどうかを分析し、ブラウザで今後のプライバシー強化機能に対する準備状況を評価します。

プライバシー重視のオリジントライアル。
図10.13. プライバシー重視のオリジントライアル。

プライバシー強化機能の中で、disableThirdPartyStoragePartitioningがもっとも広く使用されているコントロールであり、モバイルウェブサイトの10.21%で展開されていることに注目します。disableThirdPartyStoragePartitioningは、トップレベルサイトが、そのページに埋め込まれたサードパーティコンテンツのストレージ、サービスワーカー、通信APIでパーティション分割を解除（トップレベルサイトによる分離を一時的に削除）できるようにします。

これは、ウェブサイトの10%以上が、サードパーティストレージのパーティショニングによって提供される利点を無効にする機能をテストしていることを意味します。ストレージパーティショニングは、Cookieを含まない一部のストレージ関連APIに適用されることに注意してください。2番目に普及しているトライアルはFledgeBiddingAndAuctionServerで、モバイルウェブサイトの6.62%以上で展開されています。

Privacy Sandboxの提案

2019年にGoogleによって導入されたPrivacy Sandboxには、ユーザーのプライバシーと、ウェブ上の無料コンテンツやサービスを支えるオンライン広告の継続的な存続可能性とのバランスをとることを目指し、ウェブ上のプライバシー侵害行為を抑制することを目的とした、いくつかの提案が含まれています。Privacy Sandboxの提案の中でも、Topics、Protected Audience、Attribution Reportingは、それぞれターゲット広告、インタレストベース広告オークション、プライバシーを保護するコンバージョントラッキングへの影響から、大きな注目を集めています。このセクションでは、これらの提案の採用状況を測定し、ウェブサイトやアドテク（たとえば広告プラットフォーム、追跡エンティティ）がこれらの提案を組み込む準備ができているかを評価します。これらの提案の一部はChromeに限定されず、Microsoft Edgeなどの他のブラウザでもテストされていることに注意してください。

まず、これらのAPIの普及率を示します。Topics API、Protected Audience API（旧FLEDGE）、Attribution Reporting APIは、さまざまな広告配信技術においてもっとも高い存在感を示していることがわかります。これらは、上位1,000のウェブサイトのそれぞれ33%、63%、27%に存在します。上位1,000万のウェブサイトの中では、その存在感はそれぞれ7%、63%、24%に低下します。この存在は、ウェブサイトによるこれらのAPIの採用を意味するものではないことに注意してください。

Topics API

GoogleのTopics提案は、「スポーツ」や「テクノロジー」など、ユーザーの最近の閲覧行動に基づいて、大まかなトピックの小さなセットをユーザーに割り当てることで機能します。これらのトピックはユーザーのデバイスにローカルに保存され、関連性の高い広告を配信するためにウェブサイトや広告主と共有されます。ユーザーは広告主と共有されるトピックを表示し、制御することもできます。

Topics APIのプレゼンス。
図10.14. Topics APIのプレゼンス。

このAPIはHTTPヘッダーとJavaScriptの両方を介して展開できるため、これらの両方の軸にわたるTopics APIの採用を測定します。JavaScriptベースの存在（document.browsingTopics）はページの7%で見られ、ヘッダーベースの存在（sec-browsing-topics）の約4%よりも広まっていることがわかります。

FLoC APIのプレゼンス。
図10.15. FLoC APIのプレゼンス。

驚くべきことに、Topics APIの前身であるFederated Learning of Cohorts API（FLoC）は、いくつかのプライバシー問題により非推奨とされているにもかかわらず、かなりの数のページにまだ存在していることもわかります。Topics APIは現状を改善しますが、先行研究では、ユーザーのブラウザから返されるトピックを一定期間監視することで、ユーザーの再識別につながる可能性があることが示されています。

Protected Audience API

Protected Audience APIは、ブラウザによるデバイス上のオークションを可能にし、ユーザーが以前に訪問したウェブサイトから関連性の高い広告を選択します。これにより、リマーケティングやターゲット広告で通常採用されているプライバシーを侵害するデータ収集や広範な追跡が不要になります。これにより、広告主はサイトをまたいでユーザーを追跡することなく、関連性の高い広告を配信できます。

Protected Audience (FLEDGE) APIのプレゼンス。
図10.16. Protected Audience (FLEDGE) APIのプレゼンス。

Protected Audience APIで利用可能なさまざまなメソッド呼び出しの中で、navigator.joinAdInterestGroup()がサードパーティサービスによってもっとも多く使用されていることがわかります（上位1,000万のウェブサイトの63%）。

このAPIは、サードパーティサービスがブラウザに指示して、訪問ユーザーのインタレストグループをブラウザのメンバーシップリストに追加する機能を提供します。最近の研究（Calderonio et al.、Long and Evans）では、Protected Audience APIに関するさまざまなプライバシー上の欠陥が発見されています。たとえば、サードパーティのトラッカーは、サイドチャネルを使用してユーザーのインタレストグループを実際のユーザーにリンクさせ、サイトをまたいで追跡できる可能性があります。共謀するエンティティの可能性は、関連するプライバシーリスクをさらに高めます。

アトリビューションレポーティングAPI

アトリビューションレポーティングAPI（ARA）は、Google Chromeで広告のコンバージョンを測定するためのプライバシー保護メカニズムを導入しています。その目的は、パブリッシャーと広告主のウェブサイトでそれぞれアトリビューションソースとトリガーを登録する機能を提供することにより、アトリビューション測定を可能にすることです。Chromeはすべてのコンバージョンを記録し、差分プライベートレポートを生成して、遅延付きで承認されたソースに送信し、ユーザーのクロスサイトリンクを防ぎます。このメカニズムは、特定のHTTPヘッダーを使用して機能します。

  1. attribution-reporting-eligible: このヘッダーは、特定のリクエストの応答がアトリビューションレポートの対象であることを示します。
  2. attribution-reporting-register-source: パブリッシャーに広告主の広告を表示する際に、アトリビューションソースを登録するために使用されます。
  3. attribution-reporting-register-trigger: ユーザーが広告を操作したときにコンバージョンを測定するトリガーを登録するために、広告主のウェブサイトで使用されます。

私たちの分析から、ソースを登録しているサードパーティよりも、トリガーを登録しているサードパーティの方が2倍多いことがわかります。この傾向は、初期の広告表示イベントの追跡と比較して、コンバージョンの測定に重点が置かれていることを示しています。

アトリビューションレポーティングAPIのプレゼンス。
図10.17. アトリビューションレポーティングAPIのプレゼンス。

もっとも人気のあるブラウザのほとんどが、ChromeのARA、Safariのプライベートクリック測定（PCM）、MozillaとMetaによる相互運用可能なプライベートアトリビューション（IPA）などの提案で、プライバシー保護アトリビューションの分野で互いに競合しているため、ARAをより詳細に分析します。さまざまなウェブサイトでの広告デスティネーションの登録を調べます。

ARAデスティネーション登録。
図10.18. ARAデスティネーション登録。

上位1,000のウェブサイトの8.8%のパブリッシャーで、14.6%の異なる広告主がattribution-reporting-register-triggerヘッダーを使用して自身を登録するためにARAを使用していることがわかります。合計で、上位100万（上位1,000万）のウェブサイトの5.1%（2.4%）のパブリッシャーで、1.6%（0.5%）の異なる広告主がARAを採用していることがわかります。これは、広告主の採用と比較して、多くのパブリッシャーがARAを採用していないことを示しています。広告主は、広告クリックに対するユーザーのコンバージョンをアトリビュートするためにARAに依存する必要があるポストCookie時代に備えています。

関連ウェブサイトセット

関連ウェブサイトセットにより、同じ所有者のウェブサイト間でCookieを共有できます。関連ウェブサイトセットの作成と送信は、現在、Googleプロジェクトの貢献者が有効と判断した場合にチェックしてマージするGitHubリポジトリでプルリクエストを開くことで行われます。同じ関連ウェブサイトセットに属するウェブサイトは、.well-known URI .well-known/related-website-set.json に対応するファイルを配置して、それを示す必要があります。

Chromeには、Chromeチームによって検証された関連ウェブサイトセットを含むプリロードされたファイルが付属しています。執筆時点（バージョン2024.8.10.0）では、64個の異なる関連ウェブサイトセットがあります。各関連ウェブサイトセットには、プライマリドメインと、次の属性のいずれかの下でプライマリドメインに関連する他のドメインのリストが含まれています： associatedSites 、 servicesSites 、および/または ccTLDs 。これらの64個のプライマリドメインはそれぞれ、セットの一部としてセカンダリドメインに関連付けられています：60個のセットには associatedSites が、11個には servicesSites が、7個には ccTLDs が含まれています。詳細な結果については、Cookieの章を参照してください。

法律とポリシー

オンライントラッキングに対する監視が強まる中、オンライン広告主やトラッカーの責任を問う新たな法律や規制が数多く可決されています。このセクションでは、これらの規制がプライバシーに与えた影響を見ていきます。

同意ダイアログ

欧州連合における一般データ保護規則（GDPR）やカリフォルニア州消費者プライバシー法（CCPA）などのプライバシー規制の導入により、ウェブサイトはユーザーデータの収集、共有、処理（たとえばサードパーティの追跡Cookieの収集と使用）についてユーザーの同意を得る必要があります。これにより、Cookie同意ダイアログが広く使用されるようになり、ユーザーにデータ収集慣行を通知し、同意、拒否、またはカスタマイズを可能にしています。

これらの同意ダイアログはウェブ全体で普遍的な機能となっていますが、ユーザーのプライバシーを真に保護する上での有効性は議論の余地があります。多くのウェブサイトは「ダークパターン」を使用してユーザーに追跡を承諾させようとし、また、技術に詳しくないユーザーを圧倒する可能性のある複雑なオプションを提示するものもあります。Interactive Advertising Bureau（IAB）ヨーロッパは、ターゲット広告の同意を得るプロセスを標準化するために、透明性と同意のフレームワーク（TCF）を導入しました。IAB同意ダイアログは、多くのウェブサイトや広告技術企業が、パーソナライズされた広告を引き続き提供しながら、GDPRやその他のプライバシー法を遵守するために使用しています。このフレームワークは、ユーザーデータがどのように処理されるかについて透明性を提供し、パーソナライズされた広告、分析、コンテンツ配信など、さまざまな目的でユーザーが同意を与えたり差し控えたりする機能を提供することを目的としています。

私たちの調査結果は、TCFが他のプライバシーフレームワークとともに、出版社がGDPRやCCPAなどのデータ保護法を遵守しようとする中で広く実装されていることを示しています。ここでの測定は米国を拠点としており、TCFによれば、EU以外の訪問には同意バナーは不要であることに注意してください。したがって、これによりTCFの使用状況の測定値が実際よりも小さくなる可能性があります。

IABプライバシーフレームワークの存在。
図10.19. IABプライバシーフレームワークの存在。

2024年のデータは、2022年と比較してプライバシーの状況が変化したことを明らかにしています。まず、IABフレームワーク全体の普及率が増加しました。2022年には、もっとも広範なIABのプレゼンス（「IAB all」）がページの4.4%（デスクトップとモバイルの合計）で見つかりました。2024年には、TCFまたはUSPフレームワークのいずれかがホームページの5.8%に表示されます。これは、規制の監視強化やユーザーの意識向上によって、プライバシー基準の採用が拡大していることを示唆しています。

個々のフレームワークを調べると、TCFの使用（任意のバージョン）はページの4.2%に表示されますが、USPは単独でページの3.3%に存在します。ページの4.0%が最新バージョンのTCF（v2）を使用しており、これがもっとも普及しているバージョンでもあります。準拠したセットアップ（ベンダーの同意設定の存在）を持つTCF v2は、より小さなサブセットであるページの1.7%に表示されます。GDPR施行前の古いTCF v1は、0.2%とごくわずかです。

興味深いことに、IABフレームワーク全体の使用率は上昇していますが、USPの採用率は比較的安定しており、2022年の約3.4%に対し2024年は3.3%です。これは、プライバシーフレームワーク採用の全体的な成長が、主にTCF、とくにTCF v2の使用増加によって牽引されていることを示唆しています。

最後に、TCF v1からTCF v2への移行は明らかです。2022年のTCF v1には測定可能なプレゼンス（モバイルで0.3%）がありましたが、2024年には0.2%とほぼ廃止されています。TCF v2の採用は大幅に増加しており（1.9%から4%）、これは新しいGDPRに沿った同意メカニズムへの移行をさらに示しています。しかし、完全なTCF v2コンプライアンスは依然として比較的低く、その複雑な要件を完全に実装するという継続的な課題を浮き彫りにしています。

トップ10のTCF v2準拠CMP。
図10.20. トップ10のTCF v2準拠CMP。

TCF v2エコシステム内での同意管理プラットフォーム（CMP）の使用状況の分析によると、Automattic, Inc.が採用をリードしており、ページの0.67%に表示され、InMobi PTE Ltdが0.25%、Didomiが0.22%でそれに続いています。これは、特定のCMPが同意を効果的に管理するために信頼されるようになったことを示唆していますが、採用率が比較的低いことは、多くのサイトがまだ社内ソリューションやあまり広く認識されていないCMPに依存している可能性があることを意味します。

Do Not Track

Do Not Track（DNT）は、2010年代初頭に導入されたブラウザベースのプライバシーイニシアチブです。これにより、ユーザーはウェブサイトによる追跡を希望しないことを示すブラウザ設定を行えました。しかし、DNTは主に任意であり、強制メカニズムがなかったため、広く採用されるには至りませんでした。

19.8%
図10.21. デスクトップページでは、依然としてDNT（Do Not Track）HTTPヘッダーが使用されています。

DNTはユーザープライバシーにおける先駆的なアイデアでしたが、主要な広告主やトラッカーがDNTリクエストを無視することを選択し、どの法的枠組みにも祀られていなかったため、最終的には時代遅れになりました。時代遅れであるにもかかわらず、私たちの分析によると、デスクトップウェブサイトの19.8%、モバイルウェブサイトの18.4%が依然としてDNTシグナルをサポートしています。これらのサイトはDNTシグナルをチェックするかもしれませんが、これらのサイトがシグナルをどの程度遵守し、準拠しているかは不明であると指摘することが重要です。

Global Privacy Control

Global Privacy Control（GPC）は、DNTと同様に、ユーザーがプライバシー設定をウェブサイトに伝えるためのシンプルなブラウザベースのメカニズムを提供するように設計された、より最近のイニシアチブです。ただし、DNTとは異なり、GPCはCCPA（カリフォルニア州消費者プライバシー法）などの法規制に裏付けられています。

GPCを使用すると、ユーザーは自分のデータが第三者に販売または共有されることを望まないことを通知でき、企業は特定の法律の下でこの信号を尊重する法的義務を負います。主要なブラウザやプライバシー重視の拡張機能はGPCをサポートしており、ユーザープライバシーのためのより効果的なツールとして注目を集めています。

Global Privacy Controlの存在。
図10.22. Global Privacy Controlの存在。

分析によると、デスクトップサイトの55.8%、モバイルサイトの54.9%でGPC信号がJavaScriptを介してアクセスでき、これはDNT信号よりも大幅に高いことがわかります。GPCのもう1つのオプション要件は、ウェブサイトのオリジンサーバーURLに対して相対的な/.well-known/gpc.jsonエンドポイントにあるウェルノウンURLです。このリソースは、ウェブサイトがGPCを認識し、サポートしていることを示すためのものですが、同時にGPCを遵守することを保証するものではありません。私たちの測定では、モバイルサイトとデスクトップサイトのわずか0.2%しか、アクセス可能なウェルノウンエンドポイントを持っていないことがわかりました。

カリフォルニア州消費者プライバシー法

2018年に制定されたカリフォルニア州消費者プライバシー法（CCPA）は、米国で可決されたもっとも重要なプライバシー法の1つです。これにより、カリフォルニア州の住民は、収集されているデータを知る権利、データの削除を要求する権利、データの販売をオプトアウトする権利など、個人データに対する権利を与えられます。CCPAは、カリフォルニア州の住民からデータを収集または処理する場合、世界中の企業が遵守しなければならないため、ウェブに大きな影響を与えています。これにより、多くのウェブサイトで「私の個人情報を販売しない」リンクが導入され、米国でのデータプライバシーに対する意識が高まりました。

法律の下では、カリフォルニアで事業を行い、特定の規模のしきい値を満たす事業は、ユーザーが個人情報の販売または共有をオプトアウトする方法を提供しなければなりません。法律を遵守するため、カリフォルニア州司法長官室は、事業のホームページに「私の個人情報を販売しない」というテキストと標準化されたアイコンを含むリンクを配置することを推奨しています。一般的なCCPAリンクフレーズのセットを特定した先行研究に基づいて、人気度レベルに応じてサイト全体でのこれらのリンクの普及率の分析を実施しました。

ウェブサイトのホームページにおけるCCPAリンクの普及率。
図10.23. ウェブサイトのホームページにおけるCCPAリンクの普及率。

全体として、CCPAリンクを含むウェブサイトはわずか0.96%であることがわかります。また、ランクの低いウェブサイトと比較して、ランクの高いウェブサイトほどCCPAリンクを含んでいることもわかります。ランクの高いウェブサイトは、CCPAの対象となるしきい値を満たしている可能性が高いか、単に要件をより認識しているため、CCPAリンクを含んでいる可能性が高くなります。

しかし、上位1,000のウェブサイトにおけるリンクの割合はわずか7.19%であり、これは非常に低い値です。これらのサイトのうち、CCPAの対象となる要件を満たしているサイトがいくつあるかを知ることは不可能ですが、上位ランクのウェブサイトの多くは少なくとも収益のしきい値を満たしている可能性が高いため、カリフォルニアのユーザーを積極的にブロックする措置を講じない限り、対象となっているように見えます。

私たちのクロールの1つの制限は、地理的に分散しているため、カリフォルニアの訪問者にのみCCPAリンクを動的に表示するウェブサイトを正確に考慮できないことです。したがって、私たちの結果はこれらのリンクの普及率を過小評価している可能性があります。ただし、2022年に実施された先行研究によると、CCPAリンクのわずか17%しか動的に非表示にされていなかったことに注意することが重要です。

最後に、CCPAリンクでもっとも一般的に使用されている言い回しを調べます。

CCPAリンクのトップ10フレーズ。
図10.24. CCPAリンクのトップ10フレーズ。

ほとんどのサイトは、CCPAで推奨されている「do not sell my personal information」というフレーズの変形を使用しています。しかし、かなりの数のサイトには「your privacy choices」というタイトルのリンクも含まれており、その意味はあまり明確ではありません。これにより、ユーザーがこれらのサイトでオプトアウトすることがより困難になる可能性があります。

結論

私たちは、オンライントラッキングが単に普及しているだけでなく、ほぼ普遍的であり、デスクトップウェブサイトの95%、モバイルウェブサイトの94%に少なくとも1つのトラッカーが含まれていることを発見しました。GoogleやFacebookなどの主要企業は、それぞれウェブページの68%と23%に存在し、この状況を支配しています。また、トラッカーがステートフルな方法（Cookieやローカルストレージなど）とステートレスな方法（ブラウザのフィンガープリントなど）の両方を利用して、インターネット全体でユーザーを追跡していることも観察しています。

トラッカーは、プライバシー強化の取り組みを回避するために、洗練された技術を継続的に開発しています。とくに、CNAMEクローキングやバウンストラッキングなどの方法が出現し、トラッカーがファーストパーティエンティティになりすまし、ブラウザの機能を悪用して追跡活動を継続できるようになっています。

この章では、User-Agent Client HintsやReferrer Policyなど、ユーザーのプライバシーを強化するために設計されたブラウザポリシーの採用も評価しています。2022年（この分析が最後に行われた年）からこれらの機能の実装は徐々に増加していますが、ウェブ全体での採用は依然として不均一です。さらに、Topics API、Protected Audience API、Attribution Reporting APIなどのPrivacy Sandbox提案の導入は、オンライン広告におけるプライバシー保護技術への前向きなシフトを示しています。

法的な面では、GDPRやCCPAなどの規制により、同意ダイアログやIABの透明性と同意のフレームワークなどのフレームワークが急増しました。しかし、採用が限られているため、これらの措置の有効性は疑問視されています。

結果を調べる

結果を表示 クエリを表示 編集を提案する 翻訳ヘルプ

著者

引用

BibTeX 
@inbook{WebAlmanac.2024.プライバシー,
author = "Vekaria、YashとStandaert、BenjaminとOstapenko、MaxとAmjad、Abdul HaddiとDimova、YanaとMunir、ShaoorとBöttger、ChrisとIqbal、UmarとFernandez-de-Retana、AlbertoとPollard、Barry",
title = "プライバシー",
booktitle = "2024 Web Almanac",
chapter = 10,
publisher = "HTTP Archive",
year = "2024",
language = "日本語",
doi = "10.5281/zenodo.14261510",
url = "https://almanac.httparchive.org/en/2024/privacy"
}