https://www.marketechlabo.com/tags/privacy/Recent content in privacy on MarketechlaboHugo -- gohugo.ioja-jpMon, 01 Mar 2021 00:00:00 +0900https://www.marketechlabo.com/web-measurement/itp-latest/Mon, 07 Oct 2019 00:00:00 +0900https://www.marketechlabo.com/web-measurement/itp-latest/ <h2 id="itpの仕様">ITPの仕様</h2> <p>この記事ではSafari/WebKitのIntelligent Tracking Prevention（ITP）の仕様を、2026年3月現在の最新情報に基づいて解説する。各ブラウザのプライバシー対策の全体像やサードパーティcookie代替技術については<a href="/web-measurement/tracking-privacy-by-browsers/">tracking-privacy-by-browsers.md</a>を参照されたい。</p> <h3 id="itpの目的と概要">ITPの目的と概要</h3> <p>われわれウェブサイト運用者は</p> <ul> <li>cookieやローカルストレージなどを使ってブラウザにドメインのデータを保持し、</li> <li>それらのデータを必要に応じてツール間で連携する</li> </ul> <p>ことによって行動計測やコンテンツの出し分けなどのマーケティング活動を行っている。ITPはウェブサイト訪問者のプライバシー保持のためにそれを制限する仕組みである。具体的に何をやっているのかざっくりまとめると、 <figure> <picture> <img loading="lazy" decoding="async" alt="ITPの前提条件" class="image_figure image_internal image_unprocessed" src="/images/tracking-issue/itp-condition-2.png" /> </picture> </figure> この3つのケースにおいて</p> <ul> <li>cookieなどを使ったデータ保持が短期間しかできなくなる（期間の長さはケースごとそれぞれ異なる）</li> <li>リファラが使い物にならなくなる</li> </ul> <p>可能性があるということである。その結果</p> <ul> <li>コンバージョントラッキングができない</li> <li>リマーケティング広告が配信できない</li> <li>cookieを使うツール <ul> <li>GoogleアナリティクスやAdobe Analyticsなどのウェブ解析ツール</li> <li>Treasure DataなどのCDP</li> <li>ABテスト</li> <li>その他あらゆるcookieを使うツール</li> </ul> </li> </ul> <p>でデータが不正確になるリスクがある。せっかく高額なCDPなどのツールを導入しても、場合によっては使い物にならなくなるのである。</p> <h3 id="各ケースにおける挙動">各ケースにおける挙動</h3> <h4 id="ケース1-リンクデコレーション付き遷移itp-22以降">ケース1: リンクデコレーション付き遷移（ITP 2.2以降）</h4> <p>ドメインAからドメインBに遷移したとき</p> <p>前提条件:</p> <ul> <li>ドメインAが<a href="/web-measurement/itp-latest/#%e3%83%88%e3%83%a9%e3%83%83%e3%82%ab%e3%83%bc%e8%aa%8d%e5%ae%9a%e3%81%ae%e6%9d%a1%e4%bb%b6">トラッカー認定</a>されている</li> <li>リンクにクリックIDなど、トラッキング用の文字列が入っている（リンクデコレーション）</li> </ul> <p>発生する結果: ドメインBにおいて</p> <ul> <li>JavaScriptで生成するすべてのcookieの有効期限（寿命）が24時間になる</li> <li>リファラの文字列がeTLD+1（ドメイン名単位）に切り上げられる（ページパスやクエリ文字列を含まなくなる→流入元ページを特定できなくなる）</li> </ul> <p>ドメインBとドメインAのデータ連携に制約が発生するということになる。自社ドメインがトラッカー認定されてしまい、クロスドメイントラッキングでリンクにIDを付けていると、遷移先のcookieが全滅することもある。</p> <p>ITP 2.2の当初仕様ではリンクデコレーションの文字列とcookieの値が一致する場合のみ24時間制限の対象としていたが、ITP 2.3以降の実際の挙動ではリンクデコレーション付き流入時にランディングページ上のJavaScript生成cookieが広く24時間制限の対象になる。</p> <h4 id="ケース2-サードパーティリソースの読み込み">ケース2: サードパーティリソースの読み込み</h4> <p>ドメインBからドメインCのスクリプト／画像／iframe（ドメインCのリソース）を読み込むとき</p> <p>発生する結果:</p> <ul> <li>ドメインCのサードパーティcookieが使えない</li> </ul> <p>Safari 13.1（iOS 13.4）以降、トラッカー認定の有無にかかわらずすべてのサードパーティcookieがデフォルトでブロックされる。例外はない。正当な用途でクロスサイトのcookieアクセスが必要な場合はStorage Access APIを通じてユーザの許可を得る必要がある。</p> <h4 id="ケース3-javascriptによるストレージ書き込み">ケース3: JavaScriptによるストレージ書き込み</h4> <p>前提条件: なし（ページ遷移や読み込むリソースやドメインの性質によらず）</p> <p>発生する結果:</p> <ul> <li>JavaScriptで生成するあらゆるストレージの有効期限が最大で7日になる <ul> <li>cookieの設定できる有効期限が最大で7日になる（ITP 2.1以降）</li> <li>ローカルストレージ、IndexedDB、SessionStorage、Service Workerの登録とキャッシュ、Media keysが未操作7日で消去される（2020年3月アップデート以降）。ただしホームスクリーンに設置したPWAは対象外</li> </ul> </li> </ul> <p>どんなケースにおいてもJavaScriptで生成するあらゆるデータを1週間を超えて保存できないということで、強い制約である。有効期限のカウントはブラウザを実際に使用した日数で計算される（ブラウザ未使用日はカウントされない）。</p> <h3 id="トラッカー認定の条件">トラッカー認定の条件</h3> <p>「トラッカー認定される」基準は何か？</p> <ul> <li>当該ドメインがリソース（スクリプトなど）として他のドメインで読み込まれた数</li> <li>当該ドメインがiframeとして他のドメインで読み込まれた数</li> <li>当該ドメインが他のドメインで読み込まれたときの、そこからのリダイレクト（ドメイン）数</li> <li>当該ドメインにアクセスした（親フレームとして読み込まれた）ときに、そこからリダイレクトしたドメイン数</li> </ul> <p>に基づいてITPの機械学習分類モデルがオンデバイスで判定する。Googleなどはまさにこの条件を満たすが、自社ドメインがこれを満たしてしまうケースもないわけではない。特に大規模のポータルサイトやグループサイトになっていると陥りやすいし、CDNで自社ドメインを使っていると危険である。</p>https://www.marketechlabo.com/web-measurement/tracking-privacy-by-browsers/Mon, 01 Mar 2021 00:00:00 +0900https://www.marketechlabo.com/web-measurement/tracking-privacy-by-browsers/ <p>Googleは現時点では廃止自体を諦めたものの、個人のプライバシー尊重の観点からサードパーティcookieを廃止する動きを進めていた。AppleのiOSやSafariではすでにITPによってサードパーティcookieはデフォルトで使えなくなっている。 そんな中サードパーティcookieに代替する技術としてさまざまな技術をGoogle自身も開発し、他のベンダもそういった技術を開発してきた。その結果さまざまな自称「ポストcookie」「cookieレス」ソリューションが出てきているのだが、それらはどれも完全にサードパーティcookieを代替するわけではなく、これまでサードパーティcookieが担ってきた役割を部分的に違う方法で実現しようとしているものにすぎない。ここではソリューションの種類と、それらがサードパーティcookieのどんな機能を代替するのか紹介する。</p> <h2 id="サードパーティcookieの役割">サードパーティcookieの役割</h2> <p>cookieの役割にはさまざまなものがあるが、サードパーティcookieは主にドメインをまたいでブラウザを識別するために使われてきた。ファーストパーティcookieであれば自社サイトの中だけでの識別になるが、<strong>サードパーティcookieでは自社のサイトと他社のサイトで同一人物であることが判明してしまうため、ユーザの許諾なくそれを使うとプライバシーを侵害する</strong>ことになる。そこでサードパーティcookieを使う場合はユーザの許諾を得ることを必須にする（デフォルトでは無効化する）というのがサードパーティcookie無効化の流れである。 ブラウザを識別することによって</p> <ul> <li>広告のリマーケティング／リターゲティング</li> <li>広告配信や分析のためにオーディエンスリストを作る</li> <li>コンバージョン計測（ビュースルー、クリックスルー）</li> </ul> <p>一部分析用途もあるが、ほとんどは広告配信のために使われてきた。 これら個別の用途を実現するためにさまざまなソリューションが提案されることがあるが、主に以下に分類される。</p> <ul> <li>Privacy Sandbox</li> <li>Google広告の拡張コンバージョン、Facebook広告のコンバージョンAPI</li> <li>共通IDサービス</li> <li>データクリーンルーム</li> </ul> <p>これらはいずれも「ポストcookie」「cookieレス」ソリューションと称されることがあるが、それぞれ別のものなので、用途に応じて選択する必要がある。</p> <h2 id="サードパーティcookieに対する各ブラウザベンダの姿勢">サードパーティcookieに対する各ブラウザベンダの姿勢</h2> <p>サードパーティcookieに対して各ブラウザベンダはどのようにサポートしていくのか、Google（Chrome）とApple（Safari）のアップデートに見える方針を読み解いていく。</p> <h3 id="appleの方針">Appleの方針</h3> <p><strong>ITPによってサードパーティcookieが無効化されると広告の行動ターゲティングができなくなるが、それについては特にフォローすることを考えていない</strong>ようである。 またサードパーティcookieが無効化されたり、広告媒体サイトからの流入時にcookieの有効期限が著しく短くなったりすると、広告のコンバージョン計測ができなくなるが、こちらについては広告配信の成果のカウントを個人の行動がわからない形で許容している。 広告が表示されているサイトのHTMLと広告の成果が発生するサイト（自社）のHTMLとサーバ両方に細工をすることで、キャンペーン×成果地点ごとに集計されたレポートが送られてくるようになる。集計されているので、個人は特定できない。これをPrivate Click Measurementという。ウェブサイト／Safariだけでなく、iOSのアプリでも類似の実装（SKAdNetwork）が用意されている。 iOS 18／Safari 18では「高度なトラッキング・フィンガープリント保護」が追加され、トラッカーがサイト間でユーザを追跡することを完全にブロックするオプションが提供されている。またプライベートブラウジングの強化（リンクトラッキング保護、CNAMEクローキングトラッカーのブロックなど）も継続している。</p> <h3 id="googleの方針">Googleの方針</h3> <p>ユーザの同意なきトラッキングが悪であって、<strong>広告配信は必要。そのための技術はサポートする</strong>という方針のようである。広告配信のための機能としてはこれまで触れてきたターゲティングや効果測定に加え、不正対策などがある。サードパーティcookieに代わってプライバシーを保護した形でこれらを実現するための機能を開発してきたのだが、機能不十分ということでサードパーティcookieの廃止を諦めた。ただし代替技術自体はChromeに残されたままで、これらの技術をプライバシーサンドボックスといい、詳細は次の項で説明する。 Chrome 136以降では、サードパーティcookie廃止の代替としてIP Protection（IP保護）の導入が進められている。2025年Q3からシークレットモードでデスクトップとAndroid向けに段階的にロールアウト予定である。IP ProtectionはユーザのIPアドレスをマスクし、2ホッププロキシ経由でトラッキングを困難にする機能である。</p> <h2 id="privacy-sandboxプライバシーサンドボックス">Privacy Sandbox（プライバシーサンドボックス）</h2> <p>Googleをはじめとするアドテク事業者が、サードパーティcookieに記録された識別子とともにユーザの行動履歴を受け取り、配信の制御を行ってきた。つまりアドテク事業者のサーバで集中管理をしていたわけだが、その過程でアドテク事業者が個人のサイトをまたいだ行動履歴を取得する（トラッキングする）ため、プライバシーの侵害と指摘されるようになった。 そこでサーバが個人の行動履歴を受け取らない形で広告配信に必要な機能を実現する。具体的には<strong>これまでサーバが行ってきた処理の一部をブラウザに任せ、ブラウザからは履歴情報そのものを送らないようにしつつ、それでもターゲティングや効果測定、不正対策を実現する</strong>という取り組みを始めた。これがプライバシーサンドボックスである。プライバシーサンドボックスはあくまで<strong>Chrome（iOSのChromeは対象外）だけを対象にしたものであり、macのSafariやiOSのブラウザはすべて対象外</strong>である。 2025年10月時点のPrivacy Sandboxステータスでは、Topics API、Protected Audience API、Attribution Reporting APIは「廃止・削除予定（Deprecate and remove）」とされている。一方でPrivate State Tokens、Fenced Frames、Storage Access APIなどは引き続きサポートされる。最新のステータスは以下で確認できる。 <a href="https://privacysandbox.google.com/overview/status">https://privacysandbox.google.com/overview/status</a> プライバシーサンドボックスを構成する各技術要素へのリンクは以下のページにある。 <a href="https://privacysandbox.com/intl/ja_jp/open-web/">https://privacysandbox.com/intl/ja_jp/open-web/</a> これまで広告配信においてサードパーティcookieが担ってきた役割には主に以下のものがある。</p> <ul> <li>アドフラウド検知</li> <li>インタレストに基づいた広告</li> <li>オーディエンスリスト、リマーケティングリストを作る</li> <li>コンバージョン計測</li> </ul> <p>これをそれぞれ置き換える技術を紹介する。</p> <h3 id="アドフラウド検知private-state-tokens-api旧trust-token-api">アドフラウド検知：Private State Tokens API（旧Trust Token API）</h3> <p>メディアサイトでは、ボットからのアクセスに対して広告を表示させたくない。人間であることを検証することが必要となる。以前はボットでない情報を共有するためにサードパーティcookieが使われてきたが、今後はPrivate State Tokensというものを使う。 ユーザがあるウェブサイトAに訪問し、reCAPTCHAなどの入力など人間でないとできない行動をすると、<strong>ボットでないことを証明するトークンが発行</strong>される。そのトークンはブラウザに保存される。 そのユーザが広告を表示すべき媒体側のサイトB（このサイトはそのユーザがボットでないことを確認したい）に訪問すると、<strong>サイトBがあらかじめ信頼したサイト（これがAに該当する）が発行したトークンをブラウザが持っているかどうか</strong>をブラウザ上で検索する。もし照合したら、サイトBはサイトAに照合したというリクエストを送り、サイトAから<strong>照合したことを証明するレコード</strong>を受け取る。 サイトBは<strong>広告プラットフォームに対してそのレコードを付けたリクエストを送る</strong>と、広告プラットフォームから広告表示に必要なデータが返される。そしてサイトBで広告が表示され 広告インプレッションがカウントされる。 <a href="https://privacysandbox.google.com/protections/private-state-tokens">https://privacysandbox.google.com/protections/private-state-tokens</a></p>