ナビゲーションをスキップ
部 IV 章 19

Cookie

公開日：
Web Almanacのキャラクターが大きなクッキーを運んでいるヒーロー画像。別のキャラクターがパンくずを投げ、探偵帽と虫眼鏡を持った別のWeb Almanacキャラクターがクッキーの跡を追っています。
Yohan Beugin、 Sam Dutton と Yana Dimova によって書かれた。
Sam Dutton と Rowan Merewood によってレビュ。
Yohan Beugin による分析。
Barry Pollard 編集。
Sakae Kotaro によって翻訳された。

導入

Web Almanac 2024の次の章は、Cookieに焦点を当てています。Cookieには複数の機能があり、ウェブにとってある程度不可欠です。たとえば、認証、不正防止、セキュリティなどです。しかし、一部のCookieはウェブサイトを横断してユーザーを追跡し、行動プロファイルの構築に利用されることがあります。

この章では、2024年6月のHTTP Archiveクロール中に、主に上位100万のウェブサイトを訪問した際に見られたウェブCookieの普及率と構造を測定します。

さらに、クロスサイト追跡を減らすためにPrivacy Sandboxイニシアチブの一環としてGoogleがChromeに導入した、サードパーティCookieの代替メカニズムの採用について議論し、測定します。

Cookieの61%がサードパーティのコンテキストで設定されていることがわかりました。一般的に、サードパーティのCookieはオンライン追跡やターゲット広告に使用できます。このため、GoogleはすべてのサードパーティCookieを段階的に廃止し、Privacy Sandboxでその機能を置き換える、よりプライバシーに配慮したオプションを導入することを提案しました。

一方、すべてのサードパーティCookieがオンライン追跡に使用されるわけではありません。Chromeなどのブラウザには、サードパーティCookieの使用方法を制限する方法がいくつか含まれています。たとえば、パーティション化されたCookie（CHIPS）は、Cookieが最初に設定されたトップレベルサイトとは異なるトップレベルサイトからアクセスできないため、ウェブサイトを横断してユーザーを追跡することは不可能です。それにもかかわらず、もっとも普及しているパーティション化されたCookieは、広告関連のドメインによって設定されていることがわかりました。もう1つの例はSameSite Cookie属性で、これにより（ファーストパーティ）Cookieがデフォルトでクロスサイトリクエストに含まれないことが保証されます。トラッカーは、SameSite属性の値を明示的にNoneに設定することで、この設定を無効にできます。したがって、実際には、観測されたファーストパーティCookieの11%でSameSiteがNoneに設定されていることがわかりました。さらに、もっとも広く設定されているサードパーティCookieは広告と分析に使用されており、Googleがもっとも多くのウェブサイトで普及していることがわかります。

ファーストパーティのCookieも、繰り返し訪れるユーザーを追跡するために使用できます。私たちの分析から、もっとも普及しているファーストパーティのCookieは分析に使用されていると結論付けています。理論的には、同一オリジンポリシーのため、これらのCookieはクロスサイト追跡には使用できません。しかし、Cookie同期やCNAME追跡などの高度な追跡方法を使用することで、トラッカーはこの制限を回避できます。オンライン追跡方法の詳細については、プライバシーの章を参照してください。

私たちの結果は、ファーストパーティとサードパーティの両方の追跡が一般的であることを示しています。Cookieによるオンライン追跡が、依然としてウェブ上で主流であることを示しています。

定義

まず、この章で使用されるいくつかの用語について共通の理解を得ましょう。

ユーザーがウェブサイトにアクセスすると、ユーザーのウェブブラウザにHTTP Cookieを設定して保存するように要求できるウェブサーバーと対話します。このCookieは、ユーザーのデバイスにテキスト文字列で保存されたデータに対応し、後続のHTTPリクエストとともにウェブサーバーに送信されます。Cookieは、複数のHTTPリクエストにわたってユーザーに関するステートフルな情報を永続化するために使用され、認証、セッション管理、追跡を可能にします。Cookieには、プライバシーとセキュリティのリスクも伴います。

ファーストパーティCookieとサードパーティCookie

Cookieはウェブサーバーによって設定され、ファーストパーティとサードパーティの2種類のCookieがあります。ファーストパーティCookieは、ユーザーが訪問しているサイトと同じドメインによって設定されますが、サードパーティCookieは異なるドメインから設定されます。

サードパーティCookieは、サードパーティからのものである場合もあれば、トップレベルサイトと同じ「ファーストパーティ」に属する別のサイトまたはサービスからのものである場合もあります。サードパーティCookieは、実際にはクロスサイトCookieです。

たとえば、ドメインexample.comの所有者がexample.netも所有しており、ユーザーがhttps://www.example.comにアクセスしたときに次のCookieが設定されるとします。

Cookie名 設定者 Cookieの種類 理由
cookie_a www.example.com ファーストパーティ 訪問したウェブサイトと同じドメイン
cookie_b cart.example.com ファーストパーティ 訪問したウェブサイトと同じドメイン：サブドメインは関係ありません
cookie_c www.example.edu サードパーティ 訪問したウェブサイトとは異なるドメイン
cookie_d tracking.example.org サードパーティ 訪問したウェブサイトとは異なるドメイン
cookie_e login.example.net サードパーティ この例では同じ所有者が所有していても、訪問したウェブサイトとは異なるドメイン（トップレベルサイトの同じ「ファーストパーティ」からのクロスサイトCookie）
図19.1. Cookieのコンテキスト。

プライバシーとセキュリティのリスク

ウェブ追跡 Cookieは、サードパーティがウェブサイトを横断してユーザーを追跡し、閲覧行動や興味を記録するために使用されます。ターゲット広告では、このデータを利用して、ユーザーの興味に合った広告を表示します。この追跡は通常、次のように行われます。サイトに埋め込まれたサードパーティのコードが、ユーザーを識別するCookieを設定できます。その後、同じサードパーティは、ユーザーが埋め込まれている他のウェブサイトにアクセスしたときにそのCookieを取得することで、ユーザーのアクティビティを記録できます（プライバシーの章も参照）。ファーストパーティのCookieもオンライン追跡に使用できることに注意してください。Cookie同期などの方法により、サードパーティCookieの制限を回避し、異なるウェブサイト間でユーザーを追跡できます。

Cookieの盗難とセッションハイジャック Cookieは、複数のHTTPリクエストにわたる認証目的で、資格情報（セッショントークン）などのセッション情報を保存するために使用されます。しかし、これらのCookieが悪意のある攻撃者によって取得された場合、それらを使用して対応するウェブサーバーに認証できます。Cookieがウェブサーバーによって適切に設定されていない場合、セッションハイジャック、クロスサイトリクエストフォージェリ（CSRF）、クロスサイトスクリプトインクルージョン（XSS）などのクロスサイトの脆弱性の影響を受けやすくなる可能性があります（セキュリティの章も参照）。

注意事項

2024年のWeb AlmanacにHTTP Archiveが適用した方法論の詳細については、方法論のページで詳しく知ることができます。この方法論には、この章の結果に影響を与える可能性のある制限があります。

  • データは、非対話的な方法でウェブサイトを自動的に訪問することによって収集されます。ユーザーの操作は、実際にウェブサイトがCookieを設定および使用する方法を変更する可能性があります。たとえば、HTTP ArchiveのツールはCookieバナー（もしあれば）と対話しないため、これらのバナーとの対話後に設定されるCookieは、私たちの調査では観測されません。
  • ウェブサイトは、各独立したウェブサイトへの訪問が開始されるときにCookieが設定されていない米国内のサーバーから訪問されます。これは、ユーザーがウェブを閲覧しながらウェブCookieを蓄積および保存するのとはかなり異なります。訪問が実行される場所は、GDPRなどの規制や法律により、Cookieの動作に影響を与える可能性があります。
  • 各ウェブサイトについて、ホームページと、同じウェブサイトの別の1ページが訪問されます。
  • この章で提示されている結果のほとんどは、2024年6月のHTTP Archiveクロール中に正常に到達したChrome User Experience Report (CrUX)によると、もっとも訪問された上位100万のウェブサイトに基づいています。
  • この章の分析のために収集されたCookieは、各ウェブサイトページの訪問の最後に、ウェブブラウザがCookieジャーに保存しているすべてのCookieを抽出することによって取得されました。その結果、収集されたデータには、ウェブブラウザによって有効と見なされ、正常に設定されたCookieのみが含まれます。したがって、ウェブサイトが無効なCookie（大きすぎる、属性の不一致など）を設定しようとした場合、それらは私たちの分析から欠落します。

注記

この章にプロットされている図は、そのサブタイトルに（a）プロットされたデータのためにウェブサイトにアクセスするために使用されたクライアントデバイスの種類（デスクトップまたはモバイル）と（b）訪問された上位のウェブサイトの数（CrUXランクによる）を示しています。情報が指定されていない場合は、グラフの軸のいずれかにある必要があります。

Cookieの普及と構造

このセクションでは、ウェブ上でのCookieの普及率、その種類、属性について報告します。

ファーストパーティとサードパーティの普及率

ファーストパーティCookieは、ユーザーが訪問しているウェブサイトと同じドメインによって設定されますが、サードパーティCookieは異なるドメインによって設定されます定義を参照。この分析では、クライアント（デスクトップまたはモバイル）およびCrUXランク全体で、ウェブサイトに設定されたCookieのうち、ファーストパーティおよびサードパーティである割合を調べます。

ファーストパーティとサードパーティの普及率。
図19.2. ファーストパーティとサードパーティの普及率。

もっとも訪問された上位100万のウェブサイトでは、Cookieの約39%がファーストパーティで、61%がサードパーティCookieです。したがって、ウェブ上で設定されるCookieの大部分はサードパーティCookieです。また、これらのウェブサイトがデスクトップまたはモバイルクライアントを介してアクセスされるかどうかにかかわらず、この分布は非常に似ていることもわかります。これは、全体として、使用されるクライアントの種類に基づいて動作の変更がほとんどまたはまったくないことを示しています。ただし、一部のウェブサイトは、クライアントの種類に応じて動作が異なったり、フィンガープリントなどの他の追跡方法を使用したりする場合があります（詳細については、プライバシーの章を参照）。

デスクトップクライアントにおけるランク別のCookieのファーストパーティおよびサードパーティの普及率。
図19.3. デスクトップクライアントにおけるランク別のCookieのファーストパーティおよびサードパーティの普及率。
モバイルクライアントにおけるランク別のCookieのファーストパーティおよびサードパーティの普及率。
図19.4. モバイルクライアントにおけるランク別のCookieのファーストパーティおよびサードパーティの普及率。

ウェブサイトのランキング全体でCookieの種類の普及率を見ると、人気のあるウェブサイトほど、訪問頻度の低いウェブサイトよりもサードパーティCookieの割合が高いことがわかります。たとえば、上位100万のウェブサイトで報告された結果と比較して、上位1,000のウェブサイトでは、Cookieの23%と77%がそれぞれファーストパーティとサードパーティです。これは、ユーザーがもっとも訪問するウェブサイトほど、訪問頻度の低いウェブサイトよりも多くのサードパーティコード（それがより多くのサードパーティCookieを設定する）を埋め込んでいるという事実によるものと考えられます。 さらに、ランク全体での各Cookieの種類の普及率は、デスクトップクライアントとモバイルクライアントの間でかなり似ています。上位100万のウェブサイトで以前に述べた注意点は、CrUXランク全体でも当てはまることがわかります。

Cookieの属性

次に、さまざまなCookie属性の分布について説明します。さらに、SameSite Cookie属性の使用に焦点を当てます。次の2つの図は、次の属性のいずれかが設定されている各クライアントの上位100万のウェブサイトに設定されたファーストパーティおよびサードパーティCookieの割合を示しています：Partitioned、Session、HttpOnly、Secure、SameSite。各属性の詳細に入る前に、デスクトップまたはモバイルクライアント間のさまざまな属性の分布の類似性をここで再び観察しましょう。

デスクトップクライアントのCookie属性の概要。
図19.5. デスクトップクライアントのCookie属性の概要。
モバイルクライアントのCookie属性の概要。
図19.6. モバイルクライアントのCookie属性の概要。

Partitioned

パーティション化されたCookieは、パーティション化されたストレージを使用して互換性のあるブラウザによって保存されます。Partitioned属性が設定されたCookieは、同じサードパーティから、かつ最初に作成されたのと同じトップレベルサイトからのみアクセスできます。言い換えれば、パーティション化されたCookieは、ウェブサイトを横断するサードパーティの追跡には使用できず、トップレベルサイトでのサードパーティCookieの正当な使用を可能にします。詳細については、独立したパーティション化された状態を持つCookie（CHIPS）を参照してください。

上位100万のウェブサイトを訪問中にデスクトップまたはモバイルで設定されたサードパーティCookieの約6%がパーティション化されていることがわかります。次の図は、上位100万のウェブサイトのサードパーティコンテキストで設定されているもっとも一般的なパーティション化されたCookie（名前とドメイン）を示しています。各クライアント（デスクトップとモバイル）について、表示されているウェブサイトの割合で上位10個のパーティション化されたCookieのみが報告されています。 上位2つのもっとも広く使用されているパーティション化されたCookieは、デスクトップで9.9%、モバイルで8.89%のウェブサイトでyoutube.comによって設定されています。YSC Cookieは、不正行為や乱用を防ぐなどのセキュリティ目的で使用され、ユーザーセッションの終了時に期限切れになりますが、VISITOR_INFO1_LIVの主な目的は分析です（Googleのドキュメントを参照）。 グラフにリストされているCookieのほとんどは、adnxs.com、criteo.com、doubleclick.netなどの広告ドメインによって設定されています。

サードパーティコンテキストにおける上位のパーティション化されたCookie（CHIPS）。
図19.7. サードパーティコンテキストにおける上位のパーティション化されたCookie（CHIPS）。

おそらく少し驚くべきことですが、上位100万のウェブサイト（デスクトップおよびモバイルクライアント）で設定されているすべてのファーストパーティCookieの1%がパーティション化されています。しかし、ファーストパーティコンテキストでCookieをパーティション化することは、ファーストパーティCookieが定義上、そのトップレベルサイトのそのファーストパーティによってのみアクセス可能であるため、少し冗長に見えます。次の図は、各クライアントのファーストパーティコンテキストで設定された上位10個のパーティション化されたCookieを示しています。receive-cookie-deprecationは、ChromeのPrivacy Sandboxのテストフェーズに参加しているドメインによって設定されます。cf_clearanceとcsrf_tokenは、ユーザーがボット対策チャレンジを正常に完了したこと、または信頼できるウェブトラフィックを識別することを示すためにCloudflareによって設定されるCookieです。

ファーストパーティコンテキストにおける上位のパーティション化されたCookie（CHIPS）。
図19.8. ファーストパーティコンテキストにおける上位のパーティション化されたCookie（CHIPS）。

セッション

セッションCookieは、単一のユーザーセッションに対してのみ有効なCookieです。言い換えれば、セッションCookieは一時的なものであり、ユーザーが設定された対応するウェブサイトを終了するか、ウェブブラウザを閉じるかのいずれか早い方で期限切れになります。ただし、一部のウェブブラウザでは、起動時に以前のセッションを復元できるため、その場合、その以前のセッションで設定されたセッションCookieも復元されることに注意してください。

2024年6月の上位100万のウェブサイトに関する私たちの分析結果によると、ファーストパーティCookieの16%とサードパーティCookieのわずか4%がセッションCookieです（デスクトップとモバイルの両方のクライアントで）。

HttpOnly

HttpOnly属性は、CookieがJavaScriptコードからアクセスされるのを防ぎ、クロスサイトスクリプティング（XSS）攻撃に対するある程度の緩和策を提供します。HttpOnly属性を設定しても、JavaScriptから開始されたXMLHttpRequestまたはfetchリクエストとともにCookieが送信されるのを防ぐことはできません。

ファーストパーティCookieのわずか12%にHttpOnly属性が設定されていますが、サードパーティCookieではデスクトップで19%、モバイルで18%に設定されています。

Secure

Secure属性を持つCookieは、HTTPsを介して行われたリクエストにのみ送信されます。これにより、中間者攻撃を防ぎます。

ファーストパーティCookieの場合、デスクトップで23%、モバイルで22%にSecure属性があり、観測されたすべてのサードパーティCookieにSecure属性があります。実際、これらのサードパーティCookieには、Secureの設定を必要とするSameSite=None属性もあります（次のセクションを参照）。

SameSite

SameSite Cookie属性により、サイトはCookieがクロスサイトリクエストに含まれるタイミングを指定できます。

  • SameSite=Strict: Cookieは、Cookieのオリジンと同じサイトからのリクエストに応答してのみ送信されます。
  • SameSite=Lax: SameSite=Strictと同じですが、ブラウザはCookieのオリジンサイトへのナビゲーションでもCookieを送信します。これはSameSiteのデフォルト値です。
  • SameSite=None: Cookieは、同一サイトまたはクロスサイトのリクエストで送信されます。 これは、Cookieによるサードパーティの追跡を可能にするには、追跡CookieのSameSite属性をNoneに設定する必要があることを意味します。

SameSite属性の詳細については、次のリファレンスを参照してください。

デスクトップクライアントのCookieのSameSite属性。
図19.9. デスクトップクライアントのCookieのSameSite属性。
モバイルクライアントのCookieのSameSite属性。
図19.10. モバイルクライアントのCookieのSameSite属性。

各クライアントで、上位100万のウェブサイトで見られるファーストパーティCookieの約33%と、ほぼ100%のサードパーティCookieに、作成時に明示的に設定されたSameSite属性があることがわかります（注意：SameSiteは指定されていない場合、Laxがデフォルトです）。上記の2つの棒グラフは、クライアント全体でのファーストパーティおよびサードパーティCookieのこのSameSite属性の分布を表しています。クライアント間での結果の違いは、ここでもいくぶん無視できる程度であることがわかります。ほぼ100%のサードパーティCookieがSameSite=Noneであり、したがってクロスサイトリクエストで送信されます。 ファーストパーティCookieの場合、約87%がSameSite=Laxです（20%が明示的に属性を設定し、残りの67%はSameSiteが設定されていない場合のデフォルトの動作に関係します）。11%のCookieは、SameSite属性が明示的にNoneの値に設定されています。Cookieが設定される正確な目的を判断するのは難しいですが、これらのCookieの一部がファーストパーティコンテキストでユーザーを追跡するために使用されている可能性があります。SameSiteがStrictに設定されているCookieはわずか2%です。

Cookieのプレフィックス

2つのCookieプレフィックス __Host-と__Secure-は、Cookie名で使用して、安全なHTTPSオリジンによってのみ設定または変更できることを示すことができます。これは、セッション固定攻撃から防御するためです。両方のプレフィックスを持つCookieは、安全なHTTPsオリジンによって設定され、Secure属性が設定されている必要があります。さらに、__Host- CookieにはDomain属性を含めてはならず、Pathが/に設定されている必要があります。したがって、__Host- Cookieは、設定された正確なホストにのみ送り返され、親ドメインには送り返されません。

デスクトップページで観測されたCookieプレフィックス。
図19.11. デスクトップページで観測されたCookieプレフィックス。
モバイルページで観測されたCookieプレフィックス。
図19.12. モバイルページで観測されたCookieプレフィックス。

デスクトップで観測されたファーストパーティCookieの0.032%と0.030%に、それぞれ__Host-と__Secure-プレフィックスが設定されていることを測定しました。これらの数値は、サードパーティCookieでは0.001%です。これらの結果は、2015年末に最初に導入されて以来、これらのプレフィックスと関連する多層防御策の採用が非常に低いことを示しています。

上位のファーストパーティおよびサードパーティのCookieとそれらを設定するドメイン

次のセクションでは、各クライアント（デスクトップおよびモバイル）について、上位10個のファーストパーティCookie、サードパーティCookie、およびそれらを設定するドメインを報告します。Cookiepediaの結果を使用して、それらのいくつかについてコメントし、興味のある読者には詳細についてこのリソースを参照することをお勧めします。

設定された上位のファーストパーティCookie。
図19.13. 設定された上位のファーストパーティCookie。

最初の2つのファーストパーティCookie _gaと_gidは、Google Analyticsによって設定され、サイト分析レポートのクライアント識別子と統計を保存するために使用されます。ウェブサイトの大多数がGoogle Analyticsを使用しています（それぞれ60%以上と35%以上）。3番目の_fbpはFacebookによって設定され、25%のウェブサイトでターゲット広告に使用されます。

上位のサードパーティCookieとそれらを設定するドメイン。
図19.14. 上位のサードパーティCookieとそれらを設定するドメイン。

IDEおよびtest_cookie Cookieはdoubleclick.net（Google所有）によって設定され、上位100万のウェブサイトで観測されたもっとも一般的なサードパーティCookieです。これらはターゲット広告に使用されます。DoubleClickは、test_cookieを設定しようとすることで、ユーザーのウェブブラウザがサードパーティCookieをサポートしているかどうかを確認します。次にMicrosoftのMUIDが続き、これもクロスサイト追跡のためにユーザーの一意の識別子を保存するためにターゲット広告で使用されます。

Cookieを設定している上位の登録可能ドメイン。
図19.15. Cookieを設定している上位の登録可能ドメイン。

ウェブ上でCookieを設定しているもっとも一般的な10のドメインのうち、検索、ターゲティング、広告サービスに関与しているドメインしか見つかりません。この結果は、一部のサードパーティがウェブをカバーしている範囲を概説しています。たとえば、Googleが所有する広告プラットフォームDoubleClickは、上位100万のウェブサイトの44%以上にCookieを設定していますが、その他は約8%から12%です。

ウェブサイトによって設定されるCookieの数

Cookieの数（デスクトップ上位100万） ファーストパーティ サードパーティ すべて
最小値 1 1 1
p25 3 2 4
中央値 7 5 10
p75 13 17 24
p90 22 66 51
p95 46 331 323
最大値 160 632 662
図19.16. デスクトップページに設定されたCookieの数の統計。
Cookieの数（モバイル上位100万） ファーストパーティ サードパーティ すべて
最小値 1 1 1
p25 3 2 4
中央値 7 4 9
p75 12 18 24
p90 21 64 52
p95 45 327 316
最大値 168 604 645
図19.17. モバイルページに設定されたCookieの数の統計。

ウェブサイトは、全体で中央値9または10個の任意の種類のCookie、7個のファーストパーティCookie、およびモバイルおよびデスクトップクライアントでそれぞれ4または5個のサードパーティCookieを設定します。上記の表は、ウェブサイトごとに観測されたCookieの数に関する他のいくつかの統計を報告しており、以下の図はそれらの累積分布関数（cdf）を表示しています。たとえば、デスクトップでは、ウェブサイトごとに最大160個のファーストパーティCookieと632個のサードパーティCookieが設定されます。

ウェブサイトごとのCookieの数（cdf）、デスクトップページ用。
図19.18. ウェブサイトごとのCookieの数（cdf）、デスクトップページ用。
ウェブサイトごとのCookieの数（cdf）、モバイルページ用。
図19.19. ウェブサイトごとのCookieの数（cdf）、モバイルページ用。

サードパーティCookieよりも、観測されたファーストパーティCookieの最大値に近い数のファーストパーティCookieを持つウェブサイトが多いことがわかります。

Cookieのサイズ

Cookieのサイズ（デスクトップ上位100万）バイト単位 ファーストパーティ サードパーティ すべて
最小値 1 1 1
p25 26 22 23
中央値 39 36 37
p75 59 58 58
p90 148 114 128
p95 380 274 348
最大値 4087 4094 4094
図19.20. デスクトップページに設定されたCookieのサイズの統計。
Cookieのサイズ（モバイル上位100万）バイト単位 ファーストパーティ サードパーティ すべて
最小値 1 1 1
p25 26 22 23
中央値 39 37 38
p75 59 59 59
p90 149 114 130
p95 382 278 352
最大値 4086 4093 4093
図19.21. モバイルページに設定されたCookieのサイズの統計。

このセクションでは、これらのCookieの実際のサイズに焦点を当てます。2024年6月のHTTP Archiveクロール中にデスクトップで観測されたすべてのCookieのサイズの中央値は37バイトであることがわかりました。この中央値は、ファーストパーティおよびサードパーティのCookie、およびクライアント全体で一貫しています。得られた最大サイズは約4Kバイトであり、RFC 6265で定義されている制限と一致しています。HTTP Archiveツールの動作方法とCookieの収集方法のため、ウェブサイトが4Kバイトの制限を超えるCookieを設定しようとした場合、この情報は、この章で分析されたデータから欠落することに注意してください。

観測されたもっとも小さいCookieは1バイトのサイズであり、空のSet-Cookieヘッダーによって誤って設定された可能性があります。さらに、各クライアントの上位100万のウェブサイトで見られるすべてのCookieのサイズの累積分布関数（cdf）も報告します。

追跡に使用されるほとんどのCookieのサイズは、35バイトを超えています。この理由は、サイズがCookieの追跡機能に関連しているためです。トラッカーは、ユーザーを再識別できるように、ユーザーにランダムに識別子を割り当てます。したがって、識別子のサイズ（バイト数）が大きいほど、より多くのユニークなユーザーに割り当てることができます。

ウェブサイトごとのCookieのサイズ（cdf）、デスクトップおよびモバイルページ用。
図19.22. ウェブサイトごとのCookieのサイズ（cdf）、デスクトップおよびモバイルページ用。

永続性（有効期限）

Cookieの有効期間（デスクトップ上位100万）日数 ファーストパーティ サードパーティ すべて
最小値 0 0 0
p25 1 30 30
中央値 183 365 365
p75 396 365 396
p90 400 400 400
p95 400 400 400
最大値 400 400 400
図19.23. デスクトップページに設定されたCookieの有効期間の統計。
Cookieの有効期間（モバイル上位100万）日数 ファーストパーティ サードパーティ すべて
最小値 0 0 0
p25 1 30 30
中央値 183 365 365
p75 396 365 390
p90 400 400 400
p95 400 400 400
最大値 400 400 400
図19.24. モバイルページに設定されたCookieの有効期間の統計。

Cookieのサイズを調べた後、次にCookieの有効期間について見ていきましょう。Cookieは作成時に有効期限が設定されます。セッションCookieはセッションが終了するとすぐに期限切れになることを思い出してください（前のセクションを参照）。ファーストパーティCookieの有効期間の中央値は約183日または約6か月ですが、サードパーティCookieの有効期間の中央値は丸1年です。1日未満および30日後、それぞれファーストパーティCookieの25%とサードパーティCookieの25%が期限切れになります。HTTP Archiveツールの計測と収集で観測できるCookieの最大有効期間は400日であり、これはChromeがCookieのExpiresおよびMax-Age属性に課すハードリミットと一致しています。以下は、デスクトップまたはモバイルクライアントであるかどうかにかかわらず、上位100万のウェブサイトに設定されたCookieの有効期間の累積分布関数（cdf）です。

ウェブサイトごとのCookieの有効期間（cdf）、デスクトップおよびモバイルページ用。
図19.25. ウェブサイトごとのCookieの有効期間（cdf）、デスクトップおよびモバイルページ用。

グラフから、Cookieの約45%が90日後に期限切れになると推測できます。モバイルとデスクトップの両方のクライアントで同じ結果が見つかります。さらに、Cookieの75%の寿命は最大1年ですが、残りの半分は1年以上ブラウザに保存されたままです。理論的には、Cookieの寿命が長いほど、繰り返し訪れるユーザーを再識別できる期間が長くなります。このため、ほとんどの追跡Cookieは通常、より長い期間ブラウザに保存されます。

Privacy Sandboxイニシアチブ

2019年、Googleは、歴史的にサードパーティCookieやその他の追跡メカニズムに依存してきた広告やその他のユースケースの有用性を維持しながら、クロスサイト（ウェブ）およびクロスアプリ（Android）の追跡を減らすためのPrivacy Sandboxイニシアチブの立ち上げを発表しました。

Privacy Sandboxイニシアチブとは？

Privacy Sandboxは、一意の識別子の使用を減らし、秘密の追跡を制限し、スパムや詐欺と戦い、ユーザーに関連する広告を表示し、広告のコンバージョンを測定することを目的とした20以上の異なる提案で構成されています。

GoogleのPrivacy Sandboxに関する当初の計画の一部は、サードパーティCookieを非推奨にすることでしたが、最近の更新で、Googleはもはやそれが意図ではないと発表し、むしろ「人々がウェブブラウジング全体に適用される情報に基づいた選択を行えるようにするChromeの新しい体験」を導入すると述べました。同時に、Googleは「Privacy Sandbox APIを引き続き利用可能にし、プライバシーと有用性をさらに向上させるために投資を続けます」。

私たちは、Web Almanac 2024のプライバシーの章と提携して、HTTP Archiveクロールによって訪問されたウェブサイトでのPrivacy Sandbox APIの採用を測定し、結果の分析についてはその章に関心のある読者を紹介します。次に、Privacy Sandboxの一部であり、これまでCookieによって提供されていた機能を置き換えることを目的とした提案されたメカニズムの概要を示します。

Topics API

Topics APIは、サードパーティCookieを使用せずに、興味に基づいた広告を可能にします。このAPIにより、呼び出し元（広告技術プラットフォームなど）は、ユーザーのアクティビティに関する追加情報を明らかにすることなく、ユーザーについて観測した興味のあるトピックにアクセスできます。

Topics APIの採用に関するいくつかの結果については、プライバシーの章を参照してください。

Protected Audience

Protected Audience APIは、クロスサイトのサードパーティ追跡なしで、リマーケティングおよびカスタムオーディエンスを提供するためのデバイス上の広告オークションを可能にします。広告主は、ユーザーがウェブをナビゲートしている間にブラウザによって保存される興味グループにユーザーを追加できます。これにより、広告主は、広告オークションが実行されるウェブサイトにアクセスしたときに、ユーザーが属する利用可能な興味グループに入札することで、リターゲティング広告を実行できます。

Protected Audience APIの採用に関するいくつかの結果については、プライバシーの章を参照してください。

Attribution Reporting API

Attribution Reporting APIにより、ウェブサイトとサードパーティは広告のコンバージョン、つまり広告の表示またはクリックが後でたとえば購入につながった場合を測定できます。Attribution Reporting APIは、クロスサイトの識別子やCookieを使用せずに広告のコンバージョンを測定できるようにすることを目的としています。

Attribution Reporting APIの採用に関するいくつかの結果については、プライバシーの章を参照してください。

CHIPS

独立したパーティション化された状態を持つCookie（CHIPS）により、ウェブ開発者は、設定しているCookieをパーティション化されたストレージ、つまりトップレベルサイトごとに別のCookieジャーに保存したいことを指定できます。CHIPS Cookieは、この章のパーティション化されたセクションで以前に説明したパーティション化されたCookieに対応します。

関連ウェブサイトセット

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

64
図19.26. 執筆時点でGoogleによって検証された関連するプライマリウェブサイトセットの数。

Chromeには、Chromeチームによって検証された関連ウェブサイトセットを含むプリロードされたファイルが付属しています。執筆時点（バージョン2024.8.10.0）では、64の異なる関連ウェブサイトセットがあります。各関連ウェブサイトセットには、プライマリドメインと、次の属性のいずれかの下にあるプライマリドメインに関連する他のドメインのリストが含まれています：associatedSites、servicesSites、および/またはccTLDs。これらの64のプライマリドメインは、それぞれセットの一部としてセカンダリドメインに関連付けられています：60セットにはassociatedSites、11セットにはservicesSites、7セットにはccTLDsが含まれています。次の図では、各セットのセカンダリドメインの数を報告します。プライマリドメインの大多数が5つ以下のセカンダリドメインに関連付けられている場合、https://journaldesfemmes.com、https://ya.ru、およびhttps://mercadolibre.comは、それぞれ8、17、および39のセカンダリドメインにリンクされており、そのうちサードパーティのリクエストはすべてファーストパーティからのものであるかのように処理されます。

プライマリドメインごとのセカンダリドメイン。
図19.27. プライマリドメインごとのセカンダリドメイン。

証明ファイル

一部のPrivacy Sandbox APIを使用するには、API呼び出し元は、これらのAPIをクロスサイトの再識別のために乱用せず、意図されたユースケースにのみ使用することを宣言するために、登録プロセスを経る必要があります。このコミットメントが尊重されない場合の法的な影響はかなり不明確ですが、これにより、これらの呼び出し元は、これらのAPIを呼び出すために登録したドメインの.well-known URI /.well-know/privacy-sandbox-attestations.jsonに配置する必要がある証明ファイルを取得できます。

Chromeには、証明ファイルが登録されているドメインのリストを含むプリロードされたファイルが付属しています。現在、このリストには、次のAPIを呼び出すために登録した257の異なるドメイン（バージョン2024.10.7.0）が含まれています：Attribution Reporting、Protected App Signals（Androidのみ）、Private Aggregation（Chromeのみ）、Protected Audience、Shared Storage（Chromeのみ）、およびTopics。

私たちは、これらの証明ファイルを取得して解析するために、HTTP Archiveツールとは別のカスタムクローラーを使用しました。そのクローラーで232の異なるドメインの証明ファイルを正常に取得しました（一部の証明ファイルは利用可能ですが、たとえばネットワークの問題によりこのクローラーで取得できない場合があります）。次に、ChromeとAndroidの各APIに登録されているドメインの割合を報告します。これらのオリジンの大多数が、証明を必要とする5つのChrome APIのいずれかを呼び出すために登録されているのに対し、Android APIの割合ははるかに少ないことがわかります。

Privacy Sandbox API証明ファイルからの登録。
図19.28. Privacy Sandbox API証明ファイルからの登録。

まとめ

この章では、ウェブ上でのCookieの使用について報告します。私たちの分析により、複数の質問に答えることができます。

ウェブサイトによって設定されるCookieの種類は？

ウェブ上のCookieの大部分（61%）がサードパーティであることがわかりました。さらに、人気のあるウェブサイトほど、一般的にサードパーティのコンテンツを多く含むため、サードパーティのCookieを大幅に多く設定しています。さらに、サードパーティCookieの約6%がパーティション化されている（CHIPS）ことがわかります。パーティション化されたCookieは、ユーザーが訪問する各ウェブサイト（ドメイン）ごとにCookieジャーが別々であるという事実を考えると、サードパーティの追跡には使用できません。しかし、パーティション化されたCookieは、主に広告ドメインによって設定され、分析に使用されていることがわかりました。

どのCookie属性が設定されていますか？

設定されているすべてのCookieのうち、ファーストパーティCookieの16%とサードパーティCookieのわずか4%がセッションCookieです。残りのCookieは、ユーザーがブラウザを閉じても削除されないため、より永続的です。一般的に、Cookieの平均寿命（中央値）は、ファーストパーティで6か月、サードパーティで1年です。

さらに、サードパーティCookieの100%でSameSite属性が明示的にNoneに設定されており、これによりこれらのCookieがクロスサイトリクエストに含まれ、したがってそれらでユーザーを追跡できます。

誰がCookieを設定し、何に使用されていますか？

上位のファーストパーティCookieは、主に分析に使用されます。主な機能がユーザーによるウェブサイトの使用状況を報告すること、つまりファーストパーティ分析であるGoogle Analyticsは、少なくとも60%のウェブサイトで普及しています。Metaもその足跡をたどり、25%のウェブサイトでファーストパーティCookieを設定しています。

サードパーティCookieも主にGoogleによって設定されています。doubleclick.netは44%のウェブサイトにCookieを設定しています。他の上位トラッカーは、8〜12%のウェブサイトというかなり小さいリーチを持っています。一般的に、もっとも人気のあるサードパーティCookieは、主にターゲット広告カテゴリに属しています。

この章は、サードパーティCookieを完全に置き換えることを目的としたPrivacy Sandboxの概要で締めくくり、詳細な結果についてはプライバシーの章を参照してください。

結果を調べる

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

著者

  • Yohan Beugin
    Yohan Beuginは、ウィスコンシン大学マディソン校のコンピューターサイエンス学部の博士課程の学生で、セキュリティとプライバシーの研究グループのメンバーであり、Patrick McDaniel教授の指導を受けています。彼は、より安全で、プライバシーを保護し、信頼できるシステムの構築に関心があります。彼の現在の研究は、これまでのところ、オンライン広告における追跡とプライバシーに焦点を当てています。
  • Sam Dutton
    Sam Duttonは、GoogleのPrivacy Sandboxチームのデベロッパーアドボケイトで、サイトがサードパーティのCookieへの依存から移行するのを支援することに重点を置いています。Samは南オーストラリアで育ち、シドニーの大学に通い、1986年からロンドンに住んでいます。彼は以前、BBC R&DとITNでソフトウェアエンジニアとして、Decca Recordsで植字工として、Picador Booksで研究者として働いていました。
  • Yana Dimova
    Yana Dimovaは、ルーヴェン・カトリック大学のDistriNetの博士課程の学生で、プライバシーに対するユーザーの視点と、ウェブ上でそれをどのように保護できるかに焦点を当てています。彼女の研究対象は、オンライン追跡、個人データの漏洩、プライバシーとデータ保護法です。

引用

BibTeX 
@inbook{WebAlmanac.2024.Cookie,
author = "Beugin、YohanとDutton、SamとDimova、YanaとMerewood、RowanとPollard、Barry",
title = "Cookie",
booktitle = "2024 Web Almanac",
chapter = 19,
publisher = "HTTP Archive",
year = "2024",
language = "日本語",
doi = "10.5281/zenodo.14065903",
url = "https://almanac.httparchive.org/en/2024/cookies"
}