Attribution レベル 1

1. 導入

この文書は、ブラウザー向けの API を定義します。 この API により、集約された、 差分プライバシーが適用されたクロスサイト指標を収集できます。

この API の目的は、広告のアトリビューションを可能にすることです。 これらの集約指標は、API が適切に使用されることを条件として、広告パフォーマンスの理解向上に役立ちます。

1.1. Attribution

広告における attribution とは、関心対象の結果に先行する行動を 識別し、それらの行動に価値を割り当てる処理である。

広告主が関心を持つ行動は、 主に広告の表示 （インプレッションとも呼ばれる）である。 その他の行動には、広告クリック（またはその他のインタラクション）や、 利用されなかった広告表示の機会が含まれる。

広告における望ましい結果は、 広告主が広告表示を通じて改善しようとする任意の結果を含むため、 より多様である。 望ましい結果は コンバージョンとも呼ばれることがあり、 これは潜在顧客を顧客へと「転換」することを指す。 コンバージョンに該当するものには、 販売、購読、ページ訪問、問い合わせなどが含まれ得る。

この API では、行動と結果はいずれも イベント、すなわち一度だけ発生する物事である。 広告における attribution に特有なのは、 これらのイベントが同じサイト上で発生しない場合があることである。 広告は、広告主のサイト以外のサイトで表示されることが最も多い。

attribution における主な課題は、プライバシーを維持することである。 Attribution は異なるサイト上の活動を結び付ける。 attribution の目標は、コンバージョンが発生する前に同じ人物に表示された インプレッションを見つけることである。

attribution 情報が直接明らかにされた場合、 望ましくない コンテキスト横断認識を可能にし、 それによりトラッキングを可能にする。

この文書は、attribution 情報が集計サービスを用いて集計されることを保証することで、 コンテキスト横断認識を回避する。 集計サービスは、各人物がその集計に寄与した値を明らかにすることなく 集計を計算すると信頼される。

各ブラウザーインスタンスが特定のサイトの集計に寄与する情報量には 厳格な制限が設けられる。 差分プライバシーは、各寄与に追加のプライバシー保護を提供するために用いられる。

集計サービスの動作の詳細は § 6 集計 に含まれる。 使用される差分プライバシー設計は § 7 差分プライバシー で概説される。

1.2. 背景

Web の初期から、 広告はサイト作成を財政的に支援するため広く用いられてきた。

Web を他の広告媒体と区別する特徴の一つは、 広告キャンペーンの効果に関する情報を取得できることであった。

Web 広告主は、リーチ（広告を見た人数）、 フリークエンシー（各人が広告を見た頻度）、 およびコンバージョン（広告を見た人のうち、 その後その広告が促そうとしていた行動を取った人数）といった主要なメトリクスを測定できた。 比較すると、これらの測定は他のどの媒体よりもはるかに迅速かつ正確であった。

測定性能の代償はプライバシーでした。 正確かつ包括的な情報を生成するために、 広告事業者は、すべての Web ユーザーの活動を広範に追跡していました。 各ブラウザーには追跡識別子が割り当てられ、 多くの場合、クロスサイトリソースに関連付けられた Cookie が使用されていました。 関心対象となるあらゆる行動がこの識別子に対して記録され、 個人のオンライン活動に関する包括的な記録が形成されていました。

個人の行動に関する詳細な記録を持つことで、広告主は人々の特徴を推論できた。 それらの特徴により、広告に適したオーディエンスを選びやすくなり、 その効果が大幅に向上した。 これにより、より多くの情報を収集する強い動機が生じた。

オンライン広告は非常に競争が激しい。 広告を表示するサイトは、各広告枠からできるだけ多くの収益を得ようとする。 広告主は、費用に対して最も効果がある場所に広告を掲載しようとする。 これらの主体—​およびその代理として活動する仲介者—​が得る競争上の優位性は、 潜在的なオーディエンスについてより包括的な情報を持つことに依存する。

時間の経過とともに、関心対象の行動はオンライン活動のほぼあらゆる側面を含むように拡大した。 その情報を Web 外の活動と相関させる方法が考案された。 活発な取引が形成され、 さまざまな目的で取引される個人情報を扱う複数の業者が存在するようになった。

1.3. 目標

この文書は、広告を使用するサイトに対して アトリビューションを可能にする一方で、 追跡を可能にしたり助長したりする仕組み、 たとえば クロスサイト Cookieなどを回避することを目指しています。

Attribution API は、サイトに測定ツールを提供することで、 間接的かつ集合的なユーザー利益を もたらすことを目指しています。 これらのツールは、効果的に適用された場合に 広告パフォーマンスに関する洞察を提供できます。

1.4. エンドユーザーの利益

広告パフォーマンスの測定は、サイト横断の新たな情報フローを作り出す。 その情報フローは、コンテキスト横断認識というプライバシーリスクまたはコストを生じさせるため、 エンドユーザーに対する利益の観点から正当化される必要がある。

attributionの使用を通じてエンドユーザーが得る利益は間接的である。

Web サイトを訪問するエンドユーザーは、 そのサイトが表示する広告に対する主として自らの注意を通じて、 「無料」のコンテンツまたはサービスの代価を支払う。 この「価値」は広告主に生じ、 広告主はその対価としてサイトに支払う。 サイトはこの資金を、 コンテンツまたはサービスの提供を支援するために使用することが期待される。

アトリビューション測定システムへの参加は、 Web ユーザーにとって二次的なコストを伴うことになります。

アトリビューションのサポートにより、 広告主が広告戦略を改善するために利用できる情報を提供することで、 より効果的な広告が可能になります。 アトリビューションにより、望ましい成果と、 広告が表示される時間や場所、 広告が提示される人物、 広告自体の詳細などの広告の特性との間の相関関係を測定できます。 サイトは、この情報を利用して広告の活用方法を改善できます。

行動と成果を結び付けることは、 広告主がパフォーマンスを向上させる より大きな測定戦略の一部として利用できるツールです。 適切な測定により、広告主は効果的な広告により多くを費やし、 効果のない広告への支出を減らすことができます。 これにより、得られる価値に対する 広告全体のコストが低減されます。 [ONLINE-ADVERTISING]

コンテンツ発行者やサービスプロバイダーなど、 広告枠を提供するサイトは、 より効率的な広告から間接的な利益を得ます。 広告主が求める成果につながる 広告をより適切に表示できる 広告媒体は、 広告掲載に対してより高い料金を請求できます。

広告の掲載によって支援を得るサイトは、 質の高いコンテンツやサービスをより提供しやすくなります。 重要なのは、その支援がオーディエンスから均等に得られるわけではないことです。 これは、他の形態の財政的支援よりも公平になり得ます。 広告された商品に支出する傾向や能力が低い人も、 支払う余裕のある人と同じ 広告によって支えられたコンテンツやサービスを利用できます。 [EU-AD][COPPACALYPSE]

広告によって支えられる 「無料」サービスを提供できる能力には、 それらのサービスの価値に由来する 測定可能な経済的利益があります。 [FREE-GDP]

1.5. 集合的プライバシー効果

集計の使用は、適切に実装されている場合、サイトに提供される情報が個人ではなくグループに関するものとなることを保証する。

したがって、この機構の導入は、集合的プライバシーの考え方に沿った、集合的意思決定を表す。

アトリビューション測定への参加は、参加するグループが大きいほど プライバシー上のコストが低くなる。 これは、集約が、 サイトが集約結果から 個人に関する情報を抽出する能力に与える影響によるものである。

これは特に、この仕様で使用される 差分プライバシーモデルに当てはまる。 ノイズは集約時に単一の量として追加され、 その量は、集約に寄与する各個人から 消費されたプライバシーバジェットの量に 基づいている。 差分プライバシーによる保証は、 参加する個人の数によって変化しない。 参加者が増えると、このノイズが 結果の有用性に与える影響の度合いが低下する。 これにより、ノイズを いずれか一人の個人が寄与しうる値に対して大きくできる。

個々の寄与に追加されるノイズに依存する代替モデルでは、 寄与が増えるほどノイズの大きさも増加するため、 同じプライバシー目標に対してより多くのノイズが生じる。 その結果、プライバシーと有用性のバランスが悪化する。 これらのシステムで同じ有用性を実現するには、 より緩いプライバシー保護 または大幅に大きな母集団の測定 が必要となる。

参加者のコホートが大きいほど、より代表性の高い統計も得られ、 それ自体がより有用である。

アトリビューションが正当化されるのであれば、 これら2つの要因はいずれも、すべてのユーザーに対してアトリビューションを有効にする動機となる。

ユーザーエージェントがアトリビューション測定を有効にする措置を取ることは、 一部の人々には好意的に受け止められないだろう。 広告に関与することから生じるコストと利益について、 人によって受け止め方は異なる。 提案された設計では、サイトにその選択を明らかにすることなく、 アトリビューションに参加しているように見せる選択肢を利用者に提供する。§ 9.2 Attribution API の無効化を参照。

1.6. ヒストグラムを用いた Attribution

Attribution は、 一つ以上の広告掲載（インプレッション）と、 広告主が望む結果との相関を測定しようとする。

集計として考える場合、 個人に関する情報は有用ではない。 行動と結果はグループ化される必要がある。

attribution の最も単純な形式は、 広告の属性に従ってインプレッションをいくつかのグループに分割し、 コンバージョン数を数える。 グループは、広告が表示された場所、 表示された内容（「クリエイティブ」）、 広告が表示された時刻、 または誰に表示されたかといった属性から形成され得る。

これらのグループ分けと、 それぞれに帰属するコンバージョン数の集計によって、 ヒストグラムが形成されます。 ヒストグラムの各バケットは、 広告のグループごとのコンバージョン数をカウントします。 これにより、グループ間で比較できます。

異なる目的には、異なるグループ分けが使用される場合があります。 これにより、 因果関係の確立を目指す厳密な実験と、 異なる処置のより単純な比較の両方が可能になります。 たとえば、クリエイティブ（広告の内容）ごとにグループ分けすることで、 異なるクリエイティブを比較できます。

各コンバージョンで 1 より大きい値を追加すると、 単なる件数以上のものが可能になる。 ヒストグラムは値も集計でき、 これは異なる結果を区別するために用いられ得る。 インプレッションに割り当てられる値は、 コンバージョン 値と呼ばれる。 より高いコンバージョン値は、より大きな購入や、 より高く評価される任意の結果に用いられ得る。 コンバージョン値は、信用を分割するために複数のインプレッション間で分割されることもある。

1.7. 制限事項と適切な利用

Attribution API が提供する結果は、 広告戦略に関する意思決定に役立てることができます。 ただし、十分な注意を払わずに API を使用すると、 不適切な意思決定につながる誤解を招く結果が生じる可能性があります。

API が提供する情報を使用してより適切な意思決定を行うには、 その制限事項、特にバイアスや誤差の潜在的な原因を理解する必要があります。 この理解は、 API を使用するシステムの設計と、 あらゆる結果の解釈の両方に適用する必要があります。

範囲の制限

重大な制限事項として、同じブラウザー内のアクティビティのみを Attribution API で取得できます。 広告キャンペーンの範囲と効果が 単一の媒体だけに収まることはほとんどありません。 つまり、得られた測定値が 関連するすべてのアクティビティを捉えていると仮定することはできません。

非因果的効果

広告に接触する人の一部は、 広告が促そうとしている行動を すでに実行する意図を持っています。 そのような広告に成果を帰属させると、 その有効性について誤った印象を生じさせます。

広告の因果効果をより適切に測定するには、 （無作為化）対照試験、業界用語では増分効果（incrementality）の利用が必要です [INFERNO]。 基本的な広告対照試験では、 対象オーディエンスを特定し、 そのオーディエンス内の処置群に広告を表示し、 対照群には広告を表示しないかデフォルト広告を表示し、 各群の望ましい成果の差を測定します。

この API は、このような試験を支援するために使用できます。 これは、対照群と処置群を 異なるヒストグラムバケットに割り当てることで実現できる場合があります。 ただし、現在の Web プラットフォームには、 異なるサイト間でユーザーを 対照群と処置群に 一貫して割り当てるための機能がないことに注意してください。

単純なアトリビューションロジック

この API は、単純なマルチタッチ・アトリビューションアルゴリズムを提供します。 単純なアトリビューションアルゴリズムは、 意思決定に影響する形で結果にバイアスを生じさせる可能性があります。 API の将来のバージョンでは、 より高度なアルゴリズムを利用できるようになる可能性があります。

誤差の原因

分散測定システムには、 複数の誤差要因があります。 差分プライバシーは集計値に一定量のノイズを加えますが、 その量は既知です。

その他にもさまざまな理由により、 結果が測定対象を正確に反映しない場合があり、 その中には避けられないものもあります。 これには以下が含まれます。

• 参加サイトへの設定の伝播における失敗や遅延。

• インプレッションまたはコンバージョンイベントの消失を引き起こすスクリプトエラー。

• ストレージ圧迫による保存済みインプレッションの消失。

• 偶発的または悪意のあるインプレッションの記録。

• レポートの消失につながるネットワークエラー。

• 正当なイベントが無視される原因となる IVT 分類。

• 不正行為や偶発的な誤りを 誤って含める IVT 分類。

このような誤差は、測定結果に 未知の量の不確実性を加える可能性があります。 API を使用するサイトは、 これらやその他の種類の誤差にさらされるリスクを管理する責任があります。 API の将来のバージョンでは、 サイトによる誤差への対処を より適切に支援することを目指す可能性があります。

2. 動作の概要

Attribution API は、 インプレッションとコンバージョンという二つのイベントクラス間の関連について、 集計情報を提供する。

インプレッションとは、 広告主が任意の Web サイト上で行う任意の行動である。 API は、何をインプレッションとして記録できるかを制約しない。 広告主が測定しようとする典型的な行動には、次のものが含まれる。

• 広告を表示すること。

• ユーザーが何らかの方法で広告とインタラクションすること。

• 広告を表示しないこと（特に、広告キャンペーンが有効かどうかを確認しようとする対照実験の場合）。

API において、コンバージョンは、 測定対象となる結果である。 API は、何が結果と見なされ得るかを制約しない。 広告主が測定しようとする典型的な結果には、次のものが含まれる。

• 購入すること。

• アカウントに登録すること。

• Web ページを訪問すること。

この節の残りでは、 Attribution API が集計サービスと連携して 集計 attribution 測定を生成する方法を説明する。 その動作は次の図に示される。

2.1. インプレッションの記録

インプレッションが発生すると、 saveImpression() メソッドを使用して、 ブラウザーに情報の保存を要求できる。 これには、インプレッションの識別子と、 インプレッションについての追加情報が含まれる。 たとえば、広告主は追加情報を使用して、 インプレッションが広告ビューであったか広告クリックであったかを記録する可能性がある。

2.2. コンバージョンまたはインプレッションの照会

コンバージョン時に、コンバージョンレポートが 作成される。 コンバージョンレポートは、 ブラウザーが以前に保存した任意のインプレッションからの情報を含む、 暗号化されたヒストグラム寄与である。

measureConversion() メソッドは、 コンバージョンレポートを構築する方法をブラウザーに伝えるために使用される、 制限付きクエリを受け入れる。 これには、ブラウザーが保存したインプレッションから選択する値、 選択されたインプレッションに割り当てられるコンバージョン値、 およびコンバージョンレポートを構築するために必要なその他の情報が含まれる。

コンバージョンレポートにより作成されるヒストグラムは、次のように構築される。

• クエリがインプレッションを見つけなかった場合、 またはサイトのプライバシー 予算が使い果たされている場合、 すべてがゼロ（0）からなるヒストグラムが構築される。

• 一致するインプレッションが一つ以上見つかった場合、ブラウザーは last-n-touch attribution ロジックを実行して関連するインプレッションを選択する。提供されたコンバージョン 値は、attribution されたインプレッション時に指定されたバケットのヒストグラムに追加される。 その他すべてのバケットはゼロに設定される。

ブラウザーは、報告されたコンバージョンを反映するようにプライバシー予算ストアを更新する。

結果のヒストグラムは、選択された集計サービスの要件に従って集計用に準備され、サイトに返される。 これには少なくともヒストグラムの暗号化が含まれる。

この API を呼び出すサイトは、常に有効なコンバージョンレポートを受け取る。 その結果、サイトはこのインタラクションから他のサイトで何が起きたかについて何も知ることがない。

2.3. 集計

サイトは、この API の呼び出しから受け取る暗号化されたヒストグラムを収集し、 それらを集計サービスに送信できる。

サイトから暗号化されたヒストグラムの集合を受け取ると、集計サービスは次のことを行う。

1. 提供された入力から以前に集計を 計算していないこと、 および十分な数のコンバージョンレポートがあることを 確認し、

2. 十分な ノイズ を含めてヒストグラムを加算し、 差分プライバシー性を持つ集計ヒストグラムを生成し、

3. その集計をサイトに返す。

集計サービスの最終出力を、アトリビューション結果と呼ぶ。

ブラウザー実装は、上記の機能を確実に実行すると信頼される 集計サービスの集合を持つ必要がある。 提供されるサービスの集合の中から、 コンバージョンサイトは、 集計を実行するサービスの選択について 合意に達する必要がある。

ブラウザーは、集計サービスを登録するためのプログラムを確立するかもしれない。 これは、ブラウザーが Web PKI 証明書の 検証に使用する認証局を認可するために用いられる ルートストアプログラム と 性質が似ている。 そのようなプログラムの確立は、 この文書の範囲外である。

3. API の使用

Attribution API を使用するサイトは通常、 インプレッションまたはコンバージョンのいずれかを登録しますが、場合によっては同じ サイトが 両方を行うこともあります。

インプレッションを登録するために、サイトは saveImpression()を呼び出します。この API を使用するために、パラメーター値を収集する以外の準備は 必要ありませんが、 Attribution API を使用するかどうかを決定する際に、サポートされている aggregationServicesを確認すると 有用な場合があります。

ユーザーエージェントにリソースを提供する際の HTTP レスポンスに `Save-Impression` ヘッダーを含めることによって、インプレッションを登録することもできます。

コンバージョンレポートを要求するために、サイトは measureConversion()を呼び出します。 この API を呼び出す前に、 サイトはサポートされている集約サービスを選択します。 ページは、 aggregationServicesにあるサポート対象サービスのいずれかを選択できます。 選択したサービスの名前は、 measureConversion()メソッドを呼び出す際に、 AttributionConversionOptions 辞書の aggregationService メンバーとして指定されます。

3.1. サイト識別子

この API は、動作の主なスコープとして、HTML におけるサイトの定義に依存する。 三種類のサイトが認識される。

• インプレッション サイトとは、インプレッションを登録するサイトである。 このインプレッション サイトは、関連設定オブジェクトのトップレベルオリジンから、 インプレッションを保存するために saveImpression() が呼び出された時点で導出される。

• コンバージョン サイトとは、コンバージョンが発生するサイトである。 コンバージョンサイトは、 関連設定オブジェクトのトップレベルオリジンから、 measureConversion() が呼び出された時点で導出される。

• 仲介サイトとは、iframe など、 任意のサイト横断フレームから API を呼び出すサイトである。 仲介サイトは、 関連設定オブジェクトのオリジンから、 saveImpression() または measureConversion() のいずれかが呼び出された時点で導出される。 ただし、このオリジンが、それぞれインプレッションサイトまたはコンバージョン サイトと同一サイトである場合を除く。

この API はオリジンではなくサイトを使用する。 これは、プライバシー上の影響を持ち得るすべての活動を単一の主体に関連付けることに依存しているためである。 Cookie のような機能は、プライバシーに関連する情報を同一サイトのオリジン間で自由に交換できるようにし、 それがなければプライバシー予算を超過するために使用され得る。

3.2. Navigator インターフェイス

この API のすべての機能は、 navigator.attribution 属性に接続される。

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute Attribution attribution;
};

これは三つの主要な機能を提供する。

• ブラウザーがサポートする集計サービスのリスト（§ 3.3 サポートされる 集計サービスの検索）

• ブラウザーにインプレッションを保存するよう求める手段（§ 3.4 インプレッションの 保存）

• コンバージョン測定を要求する方法（§ 3.5 コンバージョンに対する アトリビューションの要求）

3.3. サポートされる集計サービスの検索

aggregationServices 属性は、 ユーザーエージェントがサポートする集約サービスの集合を 含みます。 サイトは、 measureConversion() メソッドを呼び出す際に、これらのサービスのいずれかを選択して指定します。 インプレッションを登録する前に、サポートされているサービスを照会することも 有用な場合がありますが、 これは必須ではなく、 インプレッションは単一の集約サービスにスコープされません。

const preferredServices = [
  "https://aggregator.example/tee",
  "https://aggregator.example/dap",
  "https://example.com/aggregator",
];
const supportedServices = navigator.attribution?.aggregationServices;
const serviceUrl = preferredServices.find(url => supportedServices?.has(url));

enum AttributionAggregationProtocol { "dap-18-histogram" };

dictionary AttributionAggregationService {
  required AttributionAggregationProtocol protocol;
};

[SecureContext, Exposed=Window]
interface AttributionAggregationServices {
  readonly maplike<USVString, AttributionAggregationService>;
};

[SecureContext, Exposed=Window]
interface Attribution {
  readonly attribute AttributionAggregationServices aggregationServices;
};

aggregationServices 属性は、 集計サービスを識別する URL から、 そのサービスに関するメタデータへのマッピングである。

protocol, 型は AttributionAggregationProtocol

集計サービスが使用する protocol。 同じプロトコルの異なるバージョンは異なる値を使用する。 単一のサービスプロバイダーが複数のプロトコルをサポートする場合であっても、 それぞれは異なる URL を使用する必要がある。 これにより、プロトコルの選択も指定することなく、 各サービスを URL により一意に識別できることが保証される。

識別された集計サービスを選択するために、 URL は measureConversion() への aggregationService パラメーターとして渡される。

AttributionAggregationProtocol は、異なる 集計サービスで使用される 送信プロトコルを記述する。この文書は 1 つのプロトコルを定義する:

dap-18-histogram

MPC を使用する DAP ベースのプロトコル [DAP]。§ 6.1 マルチパーティ 計算集約を参照。

3.4. インプレッションの保存

saveImpression() メソッドは、 ユーザーエージェントに、インプレッションをインプレッションストアに記録するよう要求する。

navigator.attribution.saveImpression({
  histogramIndex: 3,
  matchValue: 2,
  conversionSites: ["advertiser.example"],
  lifetimeDays: 7,
});

dictionary AttributionImpressionOptions {
  required unsigned long histogramIndex;
  unsigned long matchValue = 0;
  sequence<USVString> conversionSites = [];
  sequence<USVString> conversionCallers = [];
  unsigned long lifetimeDays = 30;
  long priority = 0;
};

dictionary AttributionImpressionResult {
};

[SecureContext, Exposed=Window]
partial interface Attribution {
  Promise<AttributionImpressionResult> saveImpression(AttributionImpressionOptions options);
};

saveImpression() への引数は次のとおりである。

histogramIndex, 型は unsigned long

measureConversion() がこの インプレッションを後続のコンバージョンと照合した場合、コンバージョン値 は、このインデックスによって識別されるヒストグラムバケットに追加されます。

matchValue, 型は unsigned long、デフォルトは 0

インプレッションに関連付けられたオプションのメタデータです。この値は、 コンバージョンから どのインプレッションがアトリビューションを受け取れるかを識別するために使用できます。

conversionSites, 型は sequence<USVString>、デフォルトは []

このインプレッションのコンバージョンが 発生し得るトップレベルのコンバージョン サイトであり、 そのドメイン名によって識別されます。 measureConversion() メソッドは、 指定されたサイトのいずれかから呼び出された場合にのみ、このインプレッションにアトリビューションを行います。 空の場合、任意のコンバージョン サイトが一致します。

conversionCallers, 型は sequence<USVString>、 デフォルトは []

このインプレッションをコンバージョン用に選択できる仲介 サイトまたはコンバージョンサイトであり、 そのドメイン名によって識別されます。 measureConversion() メソッドは、 指定されたサイトのいずれかから呼び出された場合にのみ、このインプレッションにアトリビューションを行います。 このオプションには、コンバージョンサイトと仲介サイトの両方が含まれます。 空の場合、API を呼び出すすべてのサイトが一致します。

lifetimeDays, 型は unsigned long、デフォルトは 30

正の「存続期間」（日単位）であり、これを過ぎるとインプレッションは それ以上アトリビューションを受け取れなくなります。 ユーザーエージェントは、存続期間に上限を設けるべきです。 また、ここで指定された値がその上限を超える場合は、 その値を暗黙に引き下げます。

priority, 型は long、デフォルトは 0

アトリビューション時にインプレッションを並べ替えるために使用される整数です。

3.5. コンバージョンに対する Attribution の要求

measureConversion() メソッドは、 ユーザーエージェントに、コンバージョンに対してattributionを実行し、 コンバージョン レポートを返すよう要求する。

measureConversion() メソッドは、 一致するインプレッションが見つかるかどうかに関係なく、 常にコンバージョンレポートを返す。 一致がない場合、または差分プライバシーが attribution の報告を許可しない場合、返されるコンバージョンレポートは ヒストグラムに寄与しない、すなわち一様にゼロとなる。

const measurement = await navigator.attribution.measureConversion({
  ...serviceDetails,
  ...aggregatedMeasurementDetails,
  ...selectionDetails,
  ...attributionDetails,
});
sendReportToServer(measurement.report);

dictionary AttributionConversionOptions {
  required USVString aggregationService;
  double epsilon = 1.0;

  required unsigned long histogramSize;

  unsigned long lookbackDays;
  sequence<unsigned long> matchValues = [];
  sequence<USVString> impressionSites = [];
  sequence<USVString> impressionCallers = [];

  sequence<double> credit;
  unsigned long value = 1;
  unsigned long maxValue = 1;
};

dictionary AttributionConversionResult {
  required Uint8Array report;
};

[SecureContext, Exposed=Window]
partial interface Attribution {
  Promise<AttributionConversionResult> measureConversion(AttributionConversionOptions options);
};

measureConversion() への引数は次のとおりである。

aggregationService, 型は USVString

aggregationServices に見つけられる 集計サービスからの選択。

epsilon, 型は double、既定値は 1.0

この コンバージョンレポートに費やす プライバシー バジェットの量。

histogramSize, 型は unsigned long

コンバージョンレポートで使用するヒストグラムバケットの数。

lookbackDays, 型は unsigned long

正の整数の日数です。 過去 lookbackDays 日以内に発生したインプレッションのみが、このコンバージョンに一致します。 省略した場合、最大ルックバックと同等です。

matchValues, 型は sequence<unsigned long>、既定値は []

集合であり、 インプレッションを選択するために使用できる match value の集合。

impressionSites, 型は sequence<USVString>、既定値は []

インプレッションサイトの 集合。 インプレッションサイトが この集合内にある場所で記録された インプレッションのみが、 この コンバージョンと照合する資格を持つ。 空である場合、任意のサイトが照合する。

impressionCallers, 型は sequence<USVString>、既定値は []

saveImpression() API を呼び出した可能性のある、 集合の サイトであり、 インプレッションサイトと 仲介 サイトの両方を含む。 空でない場合、 listed sites の 1 つによって記録された インプレッションのみが、 この コンバージョンと照合する資格を持つ。

value, 型は unsigned long、既定値は 1

コンバージョン 値。アトリビューションが行われ、かつ プライバシー 制限が満たされる場合、この値は コンバージョンレポートにエンコードされる。

maxValue, 型は unsigned long、既定値は 1

集計に含まれるすべての貢献にわたる最大の コンバージョン 値。 epsilon とともに、結果に追加されるランダムノイズの分布を較正するために使用される。 また、この コンバージョンレポートに費やす プライバシーバジェットの量を 決定するためにも使用される。

credit, 型は sequence<double>

複数のインプレッションにわたってコンバージョン値がどのように配分されるかを記述する、 有限の正の数の リスト。 値は、指定された順序で、 リスト内の値に比例して、選択されたインプレッションのリスト全体に分割される。 選択されたインプレッションの数がこのリスト内の値より少ない場合、 このリスト内の追加項目は無視される。 存在しない場合、コンバージョン値は 1 つのインプレッションに割り当てられる。

3.6. 仲介者の役割

この API は、仲介者が トップレベルのサイトに代わって 動作することをサポートしている。 広告は、掲載、入札、および測定を担当する独立した事業者に委任されることが多い。

仲介者によって保存されるインプレッションは、 仲介サイトの識別子を記録する。 コンバージョン測定のために インプレッションを選択する際、 仲介サイト 識別子を使用してインプレッションを選択できる。

3.7. ヒストグラム構築

概念的には、保存された各インプレッションは、 単一のヒストグラム定義を持つ。 各インプレッションは、 そのインプレッションに割り当てられる 値が 結果のヒストグラムのどこに現れるかを決定する、単一のHistogram Index 属性を持つ。

したがって、measureConversion() の各呼び出しは、同じヒストグラム定義を持つインプレッションを選択する必要がある。 これは API のすべての使用に適用されるが、 ヒストグラムの一貫した定義は、インプレッションが 複数の仲介者によって保存され、 測定される場合に特に重要である。

measureConversion() の呼び出し時に選択され得る すべてのインプレッションは、 同じヒストグラム定義を使用する必要がある。 API は、適切なインプレッションだけが選ばれることを保証するための いくつかの手段を提供する。

保存されたインプレッションについては、次のとおりである。

• Match value は、ヒストグラム定義ごとにインプレッションを分離するために使用できる。

• コンバージョンのためのインプレッションの使用は、 コンバージョンサイトの集合上の measureConversion() にのみ見えるよう制限できる。

• コンバージョンのためのインプレッションの使用は、 サイトの集合によって呼び出された measureConversion() にのみ見えるよう制限できる。

コンバージョン時点の共通 照合ロジックの一部として、次のとおりである。

• match value の集合は、 インプレッションの集合を制限する。

• Impression Site の集合は、 インプレッションが保存された インプレッションサイトを制限する。

• Impression Caller の集合は、 インプレッションを保存した コンバージョンサイトまたは仲介サイトの集合を制限する。

これらのオプションは、attribution がヒストグラムを選択する方法についてサイトに柔軟性を提供する。 これは、コンバージョンサイトによる異なるヒストグラムの使用を妨げない。 複数のインプレッションは、 measureConversion() の呼び出しが、 異なるヒストグラム定義を持つインプレッションを 決して選択しない限り、 異なるヒストグラム定義とともに保存できる。 これにより、measureConversion() を複数回呼び出すことで、 コンバージョンを複数のヒストグラムに attribution できることが保証される。

3.8. Permissions Policy 統合

仲介者へ委任する能力は、 Permission Policyによって制御される。

この仕様は二つのポリシー制御機能を定義する。

• saveImpression() API の呼び出し。 文字列 "save-impression" によって識別される。

• measureConversion() API の呼び出し。 文字列 "measure-conversion" によって識別される。

これら両方の機能に対するデフォルト許可リストは * である。

saveImpression() と measureConversion() に別々の権限を持たせることで、両方を行うページは、 サブリソースを想定される種類の活動に制限できる。

デフォルトで権限を有効にすることで、 外部サービスを統合する作業が簡素化される。

Permissions policy は、全か無かの制御のみを提供する。 プライバシー予算の一部を委任することは可能にしない。

4. API 内部構造

4.1. インプレッションストア

インプレッションストアは、 measureConversion() メソッドによって、一致する インプレッションを見つけるために使用される。

この API はサイトによるデータの保存を可能にするが、 インプレッションストアは ストレージキーを使用しない。

4.1.1. 内容

インプレッションストアは、 集合であり、インプレッションからなる。

4.1.2. 保守

ユーザー エージェントは、定期的に行うべきです。 タイムスタンプと 存続期間の値を使用して、 インプレッションストア内の有効期限が切れたインプレッションを識別して削除します。

インプレッションを有効期限が切れた直後に削除する必要はありません。 measureConversion()が、 有効期限の切れたインプレッションを アトリビューションから除外する限りです。 ただし、 ユーザー エージェントは、有効期限の切れたインプレッションを無期限に保持すべきではありません。

4.1.3. Clear-Site-Data 統合

`Clear-Site-Data` フィールド [CLEAR-SITE-DATA] は、 サイトに対し、ユーザーエージェントによって維持される状態を削除する能力を与える。 `"impressions"` 型は、 Clear Site Data § 3.1 The Clear-Site-Data HTTP Response Header Field で定義される、認識される型の一覧に追加される。

レスポンスについてサイトデータを消去する アルゴリズムが呼び出された場合、 型のリストが `"impressions"` を含むなら、 サイトについてインプレッションを消去するが呼び出され、 origin を渡す。

4.1.4. サイト名

インプレッションストアは、 三種類のサイトに関する情報を保存する。 インプレッションサイト、 任意の仲介サイト、 およびコンバージョンサイトの集合である。

これらのサイトは、すべてしなければなりません。すなわち、スキームおよびホスト 形式であり、 スキームが「https」である必要があります。 これは、ホストの単純な文字列シリアライズで サイトを識別するのに十分であることを意味します。 したがって、この API は単純な文字列を使用して サイトを表現できます。

実装が内部的に、タプルのhost 部分だけを使用してサイトを表すことも可能である。

4.2. プライバシー予算管理のための状態

ユーザー エージェントは、 プライバシー予算の消費を管理するために使用される、いくつかの状態を維持する。

• プライバシー 予算ストアは、 サイトごとおよびエポックごとの プライバシー予算の状態を記録する。

• グローバルプライバシー予算ストアは、 すべてのサイトにまたがって適用される、 エポックごとのグローバルプライバシー予算の状態を記録する。

• インプレッションサイトクォータストアは、 グローバルプライバシー予算ストアから消費するための、 インプレッション サイトごとおよびエポックごとのクォータの状態を記録する。

• エポック開始 時刻は、エポックがいつ開始するかを決定するために使用される。 この値は、 measureConversion() の呼び出しの副作用として初期化される。

• 単一の最後の閲覧履歴消去値。 これは、サイトに対する閲覧活動が 最後に消去された時点を追跡する。

• 単一のattribution budget lock は真偽値フラグであり、 プライバシー予算ストアに対する同時操作を防ぐために使用される。 そうしないと、予算の過剰消費につながる可能性がある。

プライバシー予算 ストア、グローバルプライバシー予算ストア、 およびインプレッションサイトクォータストアは、 プライバシーおよび安全予算を控除するによって更新される。

インプレッション ストアと同様に、 プライバシー予算 ストアおよび関連ストアはストレージキーを使用しない。 これらのストアには、情報の消去方法に関する追加の制約がある。 詳細は § 9.7 API 状態の消去 を参照。

attribution budget lock を真偽値フラグとして定義する選択は、 仕様上の便宜によるものである。 実装には代替構造の方が適している可能性がある。 実装は、競合の範囲を狭めるために、 エポックごとなどにこの値を分割できる可能性がある。

4.2.1. プライバシー予算ストア

プライバシー予算キーは、 次の項目からなるタプルである。

エポックインデックス

エポックインデックス

サイト

サイト

プライバシー予算 ストアは、キーが プライバシー予算キーであり、 値が32 ビット符号なし整数であるマップである。 これらの整数は、 microepsilon単位の値を格納する。 microepsilonは、 差分プライバシー [DP] で使用される 単位 epsilon 値の 100 万分の 1 である。

32 ビット整数を選択することで、epsilon の設定は 4294 の 最大 epsilon 以下に制限されます。 これは実装にとって十分すぎる値であると予想されます。

グローバル プライバシー予算ストアは、キーが エポックインデックスであり、値が 32 ビット符号なし整数であるマップであり、 microepsilon単位である。

グローバルプライバシー予算ストアは、 すべてのサイトにまたがって適用され、 各エポックで更新される単一の プライバシー予算の消費を追跡する。 これは、同じ人物の活動を複数のサイトにまたがって相関させることができる 敵対者に対する安全制限を提供する。

サイトごとのプライバシー予算ストアとは異なり、 グローバルプライバシー予算ストアは エポックインデックスのみによってキー付けされ、 サイトによってはキー付けされない。

インプレッション サイトクォータストアは、キーが プライバシー予算キーであり、 値が32 ビット符号なし整数であるマップであり、 microepsilon単位である。

インプレッションサイトクォータストアは、 単一のインプレッション サイトが一つのエポックで寄与できる「在庫」 （インプレッションに関連するプライバシー予算）の量を制限する。 これは、単一のインプレッションサイトが、 悪意をもって引き起こされ得るグローバル制限から過剰な量を消費することを防ぐ。

4.2.2. Attribution API の有効化

The Attribution API は、一時的アクティベーション消費 APIを おおよそのモデルとしている。 そこでは、ユーザーアクティベーションが 一時的に API を利用可能にする。 いくつかの違いにより、この設計は 一時的アクティベーション消費 APIと区別される:

• API は、次のいずれかの場合に短期間利用可能になります:

  • ユーザー活性化イベントを受け取った場合 （つまり、クリック、キー押下、または類似の操作）。

  • ナビゲーションがユーザーによって開始された場合 （つまり、ユーザーナビゲーション関与が "browser UI" である場合）。

• 最後の活性化から実装定義の期間内に、saveImpression() または measureConversion() のいずれかを呼び出すと、 そのサイトで API が有効になります。

• 各活性化は、この API を最大 1 つのトップレベルサイトで利用可能にする。 一時的な活性化と同様に、 そこでは活性化を消費することにより、 別の活性化が発生するまで 他の同様の API が利用不可になるが、 あるサイトでこの API を使用すると、この API は他のサイトで利用不可になる。

• API が正常に使用されると、 この API は、子孫 navigableすべてによる使用について有効化される。 トップレベル traversable の アクティブな文書 （すなわち、クロスサイトフレームを含む現在のページ上のすべてのフレーム）は、 追加の可用性チェックなしに API にアクセスできる。

• 各活性化により、API は最大 1 つのサイトで利用可能になります。 ナビゲーションによって、トップレベル traversableが 異なるサイトへ移動すると、API は無効になります。 しかし、そのナビゲーションを開始した操作を含む可能性のある 任意の活性化によって、 API が再び利用可能になる可能性があります。

これは効果として、広く一時的アクティベーションに似ている。 しかし、attribution activation は一時的アクティベーションとは別個の状態を使用し、 その状態は異なる方法で追跡される。 Attribution activation 状態は、影響を受ける Window ではなく、 トップレベル traversable上で追跡される。 その結果、attribution activation はナビゲーションをまたいで持続し、 アクティベーションがナビゲーションにつながる場合に、 新しいページの読み込み後の短い期間、 API の使用を可能にする。

別個の状態を持つことで、 attribution activation が一時的アクティベーション消費 APIと相互作用しないことが保証される。 アクティベーションを消費する API は、 Attribution API が利用可能になることを妨げない。 同様に、Attribution API を使用しても、 一時的アクティベーション消費 APIが利用可能になることを妨げない。

別個の状態追跡により、ユーザーアクティベーションを消費するユーザー操作を、 Attribution API により独立して測定できることが保証される。

ナビゲーションをまたいでアクティベーションを保持することで、広告における一般的なパターンが可能になる。 サイトは Attribution API を使用して、 インタラクションが発生した site から、 または後続の site 上で、 アクションを調べることができる。

これを実装するために、 各トップレベル traversableは、Attribution API について 2 つの状態を追跡する:

1. attribution enabled flag は、API が有効であるかどうかを追跡する boolean 値である。 この値は false に初期化される。

2. attribution activation timestamp は、 最後のユーザーアクティベーションを追跡する momentである。 この値はunix epochに初期化される。

実装は、アトリビューションアクティベーション期間も、 実装定義の期間として設定します。 これは、一時的アクティベーション期間以上であるべきですが、 ナビゲーションによる遅延によって Attribution API がアクセス不能にならないようにするには、より大きな値が 望ましい場合があります。

実装は、ナビゲーション中のページコンテンツの読み込みに伴う遅延を考慮するため、 許容時間を延長することを選択する場合があります。 固定値では、デバイスやネットワークにおける パフォーマンスの差異を考慮できない場合があります。 実装は、パフォーマンス特性に関する知識に基づいて、アトリビューションアクティベーション期間の値を 延長できます。 あるいは、実装はページの読み込み中、 タイマーを一時停止する場合があります。

4.2.3. エポック開始時刻

プライバシーバジェットエポック（またはエポック）は、 ある期間を識別する。 エポックの長さは、1 週間、すなわち 7 日に固定される。 ここで、日は 86400 秒として定義される。

エポック開始時刻は、 壁時計からの時点である。 エポックは、 各ユーザーエージェントについて、 週の中からランダムに選択された時刻に開始する。 これにより、プライバシー バジェットがゼロに達することで生じる集計の偏りが、 すべてのユーザーからのすべての貢献全体に 平均化されることが保証される。

開始時刻は、 現在の エポックを取得するアルゴリズムを呼び出した副作用として、エポックが最初に必要になったときに ユーザーエージェントによってランダムに選択される。

エポックインデックスは、特定のエポックを参照する整数である。 エポックインデックスは、 インプレッション およびエポック開始時刻に アクセスするために使用される。

この仕様のアルゴリズムはすべて、より抽象的なエポックではなく、具体的なエポックインデックスを使用する。 時点は、 現在の エポックを取得するアルゴリズムを使用して、対応するエポックのエポックインデックスに変換される。

4.2.4. 最後の閲覧履歴消去時刻

直近の閲覧履歴消去は、 閲覧履歴が最後に消去された時刻を追跡する、 壁時計を使用する時点である。 直近の閲覧履歴消去値は、 ユーザーの要求により いずれかのサイトレベル状態が消去されたときに、 現在の粗化された壁時計時刻 に更新される。 この値は最初は未設定である。

任意の最適化として、 次のすべてが true である場合、直近の閲覧履歴消去の更新を省略できる：

• 消去されるすべてのインタラクションが、 消去されていない他のインタラクションを持つサイト とのものである。

• 消去されるすべてのインタラクションが、 同じサイトとの他のインタラクションが保持された エポック中に発生したものである。

• エポック開始 時刻が設定されている。

3 つの条件がすべて真である場合、 最後の閲覧履歴消去を更新する必要はありません。 代わりに、プライバシー バジェットストアは、影響を受けるすべてのサイトとエポックから形成できる すべてのプライバシーバジェット キーの組み合わせについて、 値 0 を設定することによって 更新しなければなりません （対応するエポックインデックスを使用します）。

この最適化は、ユーザーエージェントが、 影響を受けるエポックにおける、 影響を受けるサイトとのインタラクションに関する情報を 保持していることに依存する。 これは、保持されているインタラクションのいずれもが 予算の枯渇を引き起こした可能性があるためにのみ機能する。 閲覧履歴の空白に関する情報が 公開されないことを保証するには、 予算をリセットする必要がある。

4.3. インプレッション保存アルゴリズム

暗黙の API 入力は、次のフィールドを持つ構造体です:

4.4. コンバージョン測定アルゴリズム

measureConversion() メソッドは 非同期に完了し、Attribution タスクソース上に作業をキューする。

検証済み conversion optionsは、次のフィールドを持つ構造体である：

4.4.1. Attribution ロジック

Attribution ロジックは、 コンバージョン値をヒストグラムバケットにどのように割り当てるかを決定する。

4.4.2. 共通インプレッション照合ロジック

4.4.2.1. Last-N-Touch Attribution

4.5. 実装定義値の設定

この仕様では、いくつかの実装定義の値を特定しています。 この節では、これらの値を最適に設定する方法に関する 実装向けのいくつかの推奨事項を示します。

実装は、lifetimeDays および lookbackDays に対して、実装定義の最大ルックバックを設定します。 最大ルックバックは、 正の整数の日数です。 これらの値に異なる最大値を設定しても意味はありません。なぜなら、 2 つの値のうち小さい方によって、保存されたどのインプレッションがコンバージョンに利用可能かが決まるためです。

実装は、少なくとも 30 日の最大ルックバックを設定しなければなりません。 この期間内では、実装はできる限り インプレッションサイトごとに少なくとも 1000 件のインプレッションを 保持するべきです。

実装は、可能な場合、時間および件数に関するこれらの推奨制限を超えて インプレッションを保持するべきです。 インプレッションを保存するために利用可能な容量は、 インプレッションデータを保持するために必要なストレージと、 コンバージョンレポートを生成するために必要な処理時間の両方に依存します。 サイトが利用可能な容量を超えるインプレッションの保存を要求した場合、 ユーザーから要求された場合（§ 9.2 Attribution API の無効化を参照）、 または実装定義の理由により、実装はこれらの制限に達する前に インプレッションを破棄してもかまいません。

実装がインプレッションを保持しないことを選択する理由の 1 つとして、 サイトが十分なユーザーエンゲージメントを得ていないことが考えられます。

saveImpression() およびmeasureConversion()に渡されるサイトのリストについて、 実装定義の値が選択されます。 インプレッションあたりのコンバージョンサイトの最大 数 は、conversionSitesの値の数に対する制限です。 実装は、この値を少なくとも 5 に設定しなければなりません。 インプレッションあたりのコンバージョン呼び出し元の最大 数 およびコンバージョンに対するインプレッション呼び出し元の最大 数 は、それぞれconversionCallers およびimpressionCallers の値の数に対する制限です。 実装は、これらの各値を少なくとも 10 に設定しなければなりません。 コンバージョンに対するインプレッションサイトの最大 数 は、impressionSitesの値の数に対する制限です。 実装は、この値を少なくとも 30 に設定しなければなりません。

クレジット値の最大 数について、 実装定義の値が選択されます。 これは、creditの値の数に対する制限です。 実装は、この値を少なくとも 10 に設定しなければなりません。 一致値の最大 数について、 実装定義の値が選択されます。 これは、matchValuesの値の数に対する制限です。 実装は、この値を少なくとも 30 に設定しなければなりません。

measureConversion()によって 生成されるヒストグラムのサイズは、 実装定義の最大ヒストグラムサイズ と集約サービスの最大ヒストグラムサイズの両方の制約を受けます。 最大ヒストグラムサイズには最小値は設定されません。 これは、集約技術の選択によって 制限が設定されると想定されているためです。 集約サービスの最大ヒストグラムサイズは、 集約サービスで使用される技術の選択によって 決定される固定値となります。 これは実装定義ではありません。

4.5.1. プライバシーおよび安全制限パラメーター構成

ユーザー エージェントは、次について値を定義することで、 プライバシーバジェットおよび安全上の制限を構成する：

• サイトごとの プライバシー予算 (ε_site) は実装定義です。 差分プライバシー集約を用いた実験では、 1（より高いプライバシー）から 10（より高いパフォーマンス）までの範囲の値で 妥当なパフォーマンスを達成できることが示されています。

• エポックごとのグローバルプライバシー予算 (ε_global) は、 エポックごとにすべてのサイト全体で利用可能な最大プライバシー予算であり、 マイクロイプシロン単位で指定されます。 実装は、この値を エポックごとのサイトあたりのプライバシー予算の倍数として設定するべきです。

• エポックごとのインプレッションサイト割り当て量 (ε_imp-quota) は、 単一のインプレッションサイトが エポックごとのグローバルプライバシー予算から消費可能にできる最大プライバシー予算であり、 マイクロイプシロン単位で指定されます。 実装は、この値を エポックごとのサイトあたりのプライバシー予算の倍数として設定するべきです。

サイトごとの予算の倍数として安全制限を設定することで、 API を複数のサイトでどのように使用できるかが決まります。 この倍数を設定する際、 実装は、予算を使用する可能性のある サイト数として何を想定するかを考慮する必要があり、 予算を完全には使用しないサイトを考慮して その値を下方調整することも考えられます。

サイトごとの予算の倍数として安全制限を設定すると、 共有制限を使い果たすには多くのサイトによる協調が必要になることが保証され、 これらの制限は主要なプライバシーメカニズムとしてではなく、 主として悪用に対する保護手段として有用になります。

5. HTTP API

5.1. インプレッションの保存

`Save-Impression` は、 Dictionary Structured Headerであり、 ユーザーエージェントに saveImpression() API を呼び出すよう要求する応答に設定される。

Save-Impression: histogram-index=3, match-value=2, conversion-sites=("advertiser.example"), lifetime-days=7

次のキーが定義されており、 saveImpression() に渡される AttributionImpressionOptions 辞書のメンバーに対応する。省略された 任意キーの既定値は、対応する AttributionImpressionOptions フィールドと同じ方法で扱われる。不明な辞書キーは無視され、 不明なパラメーターも同様に無視される。

conversion-sites

conversionSites の値。 文字列を含む 内部リストである。 各文字列値は A-label のみを使用するドメイン名を含む。 したがって、国際化 ドメイン名はpunycodeを使用する必要がある。 このキーは任意である。

conversion-callers

conversionCallers の値。 文字列を含む 内部リストである。 各文字列値は A-label のみを使用するドメイン名を含む。 したがって、国際化 ドメイン名はpunycodeを使用する必要がある。 このキーは任意である。

histogram-index

histogramIndex の値。 32 ビット符号なし整数範囲内の 整数である。このキーは必須である。

priority

priority の値。 32 ビット符号付き整数範囲内の 整数である。このキーは任意である。

match-value

matchValue の値。 32 ビット符号なし整数範囲内の 整数である。このキーは任意である。

lifetime-days

lifetimeDays の値。 正の整数である。このキーは任意である。

5.2. コンバージョンの測定

`Measure-Conversion` は、 Dictionary Structured Headerであり、 ユーザーエージェントに measureConversion() API を呼び出すよう要求する応答に設定される。

Measure-Conversion: aggregation-service="https://aggregator.example/tee", histogram-size=20, epsilon=1.0, lookback-days=14, impression-sites=("publisher.example" "other.example"), impression-callers=("ad-tech.example"), match-values=(2), credit=(0.25 0.25 0.5), value=3, max-value=7, report-url="https://report-handler.example/foo"

次のキーが定義されており、 measureConversion() に渡される AttributionConversionOptions 辞書のメンバーに対応する。省略された 任意キーの既定値は、対応する AttributionConversionOptions フィールドと同じ方法で扱われる。不明な辞書キーは無視され、 不明なパラメーターも同様に無視される。

aggregation-service

aggregationService の値。 文字列である。このキーは必須である。

epsilon

epsilon の値。 正のdecimalまたはintegerである。 このキーは任意である。

histogram-size

histogramSize の値。 正の整数である。このキーは必須である。

lookback-days

lookbackDays の値。 正の整数である。このキーは任意である。

match-values

matchValues の値。 非負の整数を含む 内部リストである。 このキーは任意である。

impression-sites

impressionSites の値。 文字列を含む 内部リストである。 各文字列値は A-label のみを使用するドメイン名を含む。 したがって、国際化 ドメイン名はpunycodeを使用する必要がある。 このキーは任意である。

impression-callers

impressionCallers の値。 文字列を含む 内部リストである。 各文字列値は A-label のみを使用するドメイン名を含む。 したがって、国際化 ドメイン名はpunycodeを使用する必要がある。 このキーは任意である。

credit

credit の値。 正のdecimalまたは 正のintegerを含む 内部リストである。このキーは任意である。

value

value の値。 正の整数である。このキーは任意である。

max-value

maxValue の値。 正の整数である。このキーは任意である。

report-url

結果として生成されるレポートがある場合に、そのレポートが POST される 潜在的に信頼できる URLを含む文字列です。 URL はレスポンス URL に対する相対 URL であってもかまいません。 そのスキームは 「https」でなければなりません。 このキーは必須です。

5.3. Fetch monkey patch

HTTP-network fetch を次のように変更する:

6. 集約

An 集約 サービスは、複数のアトリビューション情報を受け取り、 集約メトリックを生成する。

ユーザーエージェント実装は、集約に関して異なる要件を持つことになる。 しかし、集約処理にはいくつかの共通要素がある。

まず、ユーザーエージェントは、 集約サービスに関する情報で構成されるか、 あるいはそれを取得する必要がある。 これには、サポートされる集約方式と、 必要な構成が含まれる。

各集約方式は、 ヒストグラムがどのように行われるかを定義する必要がある：

• 集約のために準備される、

• 暗号化される、

• 必要なメタデータで注釈付けされる、そして

• 集約のために集約サービスへ送信される。

集約方式はまた、 集約結果がサイトによってどのように取得されるかを定義する必要がある。

6.1. マルチパーティ計算による集約

A マルチパーティ計算 (MPC) システムとは、 複数の独立した主体が関与し、 合意された関数を協調して計算するものである。

この仕様は、Prio [PRIO] および 分散集約プロトコル (DAP) [DAP] に基づく MPC システムを使用する。 これは、入力に対するクライアント提供の正当性証明に依存することを特徴とする 二者間 MPC システムである。 これにより、システムへの送信サイズが多少増加するという控えめなコストで、 非常に効率的な MPC 動作が可能になる。

MPC を使用する集約サービスは、 事前定義された関数を計算するために協力する 2 つ以上の独立したサービスから構成される。

MPC が提供する基本的な保証は、 関数の定義された出力のみが、 明確に定義された漏えいとともに、 任意の主体に明らかにされることである。

MPC の保証は、 参加する主体の部分集合が誠実である範囲でのみ成り立つ。 Prio で使用される二者間 MPC では、 プライバシー、すなわち入力の機密性は、 いずれか一方の MPC オペレーターが誠実であり続ける限り維持される。 この MPC 構成は、いずれかの MPC オペレーターによる 出力の改ざんに対しては保護しない。

6.1.1. Prio と DAP

dap-18-histogram 集約方式は、Prio [PRIO] および分散集約プロトコル (DAP) [DAP] を使用する。 具体的には、この集約方式は、 Prio3L1BoundSum [PRIO-L1] 検証可能分散集約関数 (VDAF) [VDAF] を使用する。

DAP と Prio3L1BoundSum インスタンス化は、レポートがどのように準備され、 暗号化され、集約のために送信されるかを定義する。 DAP はまた、集約値がどのように取得されるか、 およびユーザーエージェントが集約サービスについて取得する必要のある 構成を定義する。

Prio3L1BoundSum を使用する際、 レポートには、MPC に参加するノードが 送信されたヒストグラムの合計が設定値未満であることを 確認できるようにする分散ゼロ知識証明が含まれる。 Prio3L1BoundSum は、 ヒストグラム合計が 2 の累乗未満であることのみを検証できる。 つまり、証明は、 正の整数値 n について合計が 2ⁿ 未満であることを確認する。

レポートを構築するために、 証明は、maxValue より大きい次の 2 の累乗である値に基づいて生成される。 これは、集約サービス が、 maxValue と次の 2 の累乗との間のレポートを拒否できないことを意味する。 その結果、悪意のある ユーザーエージェント は、 maxValue の値の最大 2 倍を集約ヒストグラムに寄与するレポートを 生成する可能性がある。 この証明は、maxValue が 2ⁿ − 1 に等しい場合に、 過剰な寄与の機会がないことを保証する； このような攻撃の相対的な影響は、 maxValue を、他の制約が許す限り 2ⁿ − 1 に近く設定することで 低減できる。

6.1.2. DAP 拡張

DAP への拡張 [DAP-ATTRIBUTION] は、このアプリケーションに必要である：

• コレクター アイデンティティ (collector_identity) は、集約値の要求に責任を持つ主体を 識別する。 この拡張の値は API 呼び出し元のアイデンティティを符号化し、 それは 仲介サイト または コンバージョンサイト である。 コレクターアイデンティティ拡張は、DAP タスク全体に適用される。

• バジェット ソース (budget_source) は、プライバシーバジェット を消費した主体を識別する。 この拡張の値は、コンバージョンサイト のアイデンティティを符号化する。 バジェットソース拡張は、DAP タスク全体に適用される。

• プライバシー バジェット (privacy_budget) は、集約サービスが、集約タスクで構成されたものよりも 少ないプライバシーバジェットしか受け取っていないレポートを 集約しないことを保証する。 プライバシーバジェット拡張は各レポートに適用される。

ユーザーエージェントは、生成するレポートを構築するために これらの拡張を使用する。

6.1.3. DAP 向けレポート暗号化

6.2. アンチリプレイ要件

ブラウザーによって生成されるコンバージョンレポートは、 レポートを要求したサイトによって消費されたプライバシー バジェット の量に結び付けられる。

集約 サービスは、同じレポートを複数回受け入れないことを保証しなければなりません。

7. 差分プライバシー

この設計は、そのプライバシー設計の基礎として 差分プライバシー の概念を使用する。 [PPA-DP]

差分プライバシー とは、システムによって明らかにされる 私的情報の量を保証できる プライバシーの数学的定義である。 [DP] 差分プライバシーは、このシステムにおいて プライバシーを保護する唯一の手段ではないが、 最も厳密に定義され分析されている。 そのため、最も強いプライバシー保証を提供する。

差分プライバシーは、ランダム化されたノイズを使用して、 集約されたデータセットへの 私的データの寄与を隠す。 ノイズの効果は、データセットへの 個々の寄与を隠しつつ、 あらゆる集約分析の有用性を保持することである。

差分プライバシーを適用するには、 どの情報が保護されるかを定義する必要がある。 このシステムでは、保護される情報は、 単一のユーザー プロファイルのインプレッションであり、 単一のユーザーエージェント上で、 単一のエポックにわたり、 コンバージョンを登録する単一のウェブサイトについてのものである。 § 7.1 プライバシー単位では、この設計の含意を より詳しく説明する。

このアトリビューション設計は、 個別差分プライバシー と呼ばれる差分プライバシーの一形態を使用する。 このモデルでは、各ユーザーエージェントが、 寄与される情報を制限することを それぞれ個別に責任を負う。

この API の個別差分プライバシー設計には、 3 つの主要な構成要素がある：

1. ユーザーエージェントは、プライバシーバジェットを使用して、 コンバージョンレポートを通じてデバイスから出る インプレッションに関する情報量を制限する。 § 7.2 プライバシーバジェットでは、これをさらに詳しく扱う。

2. 集約 サービスは、任意のコンバージョンレポートが、 ユーザーエージェントによってそのために計上された プライバシーバジェットに従ってのみ 使用されることを保証する。 § 6.2 アンチリプレイ要件では、集約サービスに対する要件を より詳しく説明する。

3. ノイズは集約サービスによって追加される。 § 7.3 差分プライバシーメカニズムでは、使用される可能性のある メカニズムを詳述する。

これらの対策を合わせることで、 各プライバシー単位について公開される情報に 制限が課される。

7.1. プライバシー単位

差分プライバシーの実装には、 何が保護されるかについての明確な定義が必要である。 これはプライバシー 単位として知られ、 プライバシー保護を受ける主体を表す。

このシステムは、3 つの値の組み合わせである プライバシー単位 を採用する：

1. ユーザーエージェントプロファイル。 つまり、単一の人物によって使用される ユーザーエージェントのインスタンス。

2. サイトであり、 インプレッションに関する情報を要求するもの （コンバージョンサイト）。

   インプレッションを登録するサイト （インプレッションサイト） は考慮されない。 それらのサイトは、このシステムから直接情報を受け取らない。

3. 現在のエポック。

これらの値のいずれかが変化すると、新しいプライバシー単位が生成され、 その結果、別個のプライバシーバジェットが生じる。 人が訪問する各サイトは、各エポックごとに 有界な量の情報を受け取る。

理想的には、プライバシー単位は 単一の人物である。 理想的ではあるが、有用なシステムを開発しつつ 人物との完全な対応を保証することは不可能であり、 それにはいくつかの理由がある：

• 人々は複数のブラウザーや複数のデバイスを使用し、 しばしば相互に調整しない。

• すべてのウェブサイトを含む単位は、 1 つのサイトによって使い尽くされ、 他のサイトが情報を一切得られなくなる可能性がある。

• 広告は継続的な活動である。 新しいデータのためにプライバシーバジェットを割り当てなければ、 サイトはそのバジェットを永久に使い尽くしてしまう可能性がある。

7.1.1. プライバシー特性とその制限の形式的分析

Attribution におけるプライバシー保護は多層的です：

1. サイトごとのバジェットは、いずれか 1 つのコンバージョンサイトがユーザーについて知り得る情報量を制限します。

2. グローバルバジェットは、すべてのサイトがユーザーについて知り得る情報量に対する最終的な上限を提供します。

3. インプレッションサイトのクォータは、任意の 1 つの インプレッションサイトにおけるユーザーのアクティビティについてコンバージョンサイトが知り得る情報量を制限します。

4. 各ユーザーアクションの後に維持されるカウンターは、API にデータを保存したり API から情報を得たりできる サイトの数を制限します。

この仕様における形式的なプライバシー分析は、2 つの論文に基づいています。 1 つ目の [PPA-DP] は、オンデバイスの Individual DP 会計の理論を 確立しています。2 つ目の [PPA-DP-2] は、サイトごとのバジェットおよびグローバルバジェットによって提供される 数学的なプライバシー保証へと分析を拡張しています。

サイトごとのバジェットは、主要なプライバシー保護とみなすことができます。 サイトごとのバジェットは、意味のある DP 保証を提供するように構成するべきです。 しかし、[PPA-DP-2] の分析では、これらの保証を制限する 2 つの仮定が特定されています：

1. データ生成におけるサイト間適応性がないこと。 サイトの照会可能なデータストリーム（インプレッション およびコンバージョン）は、他の サイトからの過去の DP アトリビューション結果とは独立して生成されなければなりません。

2. サイト間で共有される制限を介した漏洩がないこと。 あるサイトからのクエリは他のサイトに どのレポートが送出されるかに影響してはなりません。

要するに、実際にはどちらの仮定も成立しません。

サイト間適応性がないという仮定が必要なのは、システムに複数のサイトが関与し、それらが時間の経過とともに 同じユーザーとやり取りする可能性があるためです。 サイトは、互いの DP 測定結果に基づいてユーザーに表示する広告を変更します。たとえば、ある 広告主がアトリビューション 結果から、より優れた広告を作成する方法を学習した場合、一部のユーザーは 競合他社ではなくそのサイトでコンバージョンする可能性があります。この場合、あるサイトが得た情報は、そのサイト自身の サイトごとのバジェットに対してのみ計上されるにもかかわらず、競合他社に見えるデータ（またはデータの欠如）を変化させますが、 これはそれら競合他社のサイトごとのバジェットには計上されません。

継続的な測定を提供するどのシステムにもこの性質があるため、結論としては この制限を受け入れるほかありません。この制限は、グローバル DP バジェットおよび共有クォータを設けることを正当化する理由の一部であり、 それが 2 つ目の仮定につながります。

複数のサイトにまたがる共有制限が存在する場合、サイト間漏洩がないという仮定が必要です。そのような 共有制限の一例は、グローバル DP 保証の提供を目的とするグローバル安全制限です。 一部のサイトからの measureConversion() リクエストによって 共有制限 に達した場合、他のサイトへのレポートが フィルタリングされる可能性があります。たとえば、インプレッションがあることを知っているサイトは、共有制限 に達したかどうかについて何らかの情報を得ます。この情報は集約されノイズが加えられているものの、 バジェットを使い果たしたサイトについて、そのサイトのサイトごとのバジェットを超える情報となります。

共有制限を介した漏洩があるため、それらの制限は不正利用を制限する手段としてのみ使用することが動機付けられます。共有 制限をサイトごとのバジェットの大きな倍数に設定すると、共有制限を悪用しようとするには 少なくともその数のサイトによる協調が必要になります。倍数を大きくすると、共有制限は プライバシー保護の手段としては有用性が低くなり、サービス拒否や 同様の形態の不正利用に対する保護手段としてより適するようになります。

これに対して、分析では、グローバルバジェットは、これらの制限なしに妥当な グローバル個人 DP 保証を提供するよう実装できることが示されています。しかし、多数のサイトによる API の使用をサポートするには、 グローバルバジェットをサイトごとのバジェットのかなり大きな倍数に設定する必要があります。これは、 それが提供する DP 保証はどのような仮定にも依存しない一方で、それ単独では意味のある DP 保護を提供できないことを意味します。したがって、サイトごとのバジェットが主要な DP 保証を提供します。グローバルバジェットは、 悪意のあるサイトによる協調攻撃が発生した場合のフォールバックとみなすことができます。

グローバル DP バジェットは、多数のサイトにわたってユーザーの識別情報をリンクし、 サイトごとのバジェットを組み合わせることができるサイトに対する保護にもなります。サイトごとのモデルではこの可能性は考慮されていませんが、一部の サイトがこの能力を持つことは一般的です。特に、これには ID プロバイダー、ユーザー 識別子（電子メールアドレスや電話番号など）を受け取るサイト、ナビゲーショントラッキングを正常に使用するサイト [NAV-TRACKING-MITIGATIONS]、および何らかの理由で サイト間 Cookie を使用できるサイト [WEB-WITHOUT-3P-COOKIES] が含まれます。複数の サイトにまたがって Attribution を使用することは、そのようなサイトにとって協調上の課題となり得ますが、サイトが アクティビティを単一の個人にリンクする能力を持つ可能性は、システムのプライバシーを 包括的に分析する際に無視できません。

7.1.2. ブラウザーインスタンス

各ブラウザーインスタンスは、別個のプライバシーバジェットを管理する。

ブラウザーインスタンス間の調整は可能かもしれないが、 期待されてはいない。 その調整により、公開される情報の総量を減らすことで プライバシーを改善できる可能性がある。 また、あるブラウザーインスタンス上のインプレッションが 別のブラウザーインスタンス上でコンバージョンされることを可能にすることで、 アトリビューションの有用性を改善する可能性もある。

異なる実装間の調整は、 現在この作業の範囲外である。 実装は、同じ人物のものとして知られているインスタンス間で ある程度の調整を行うことができるが、 これは必須ではない。

7.1.3. サイトごとの制限

ウェブサイトに公開される情報は、サイト に基づいて行われる。 これは、他のプライバシー関連機能で使用される同じ境界と一致する。

オリジンのようなより細かいプライバシー単位は、 追加情報の取得を些細なものにしてしまう。 同じ人物に関する情報を 複数のオリジンから収集できる。 その情報は、その後、Cookie [COOKIES] などを使用して、 サイト内での情報の自由な流れを悪用することで結合できる。

§ 7.2.2 安全制限では、この制限を悪用する攻撃と、 それらの攻撃から保護するために ユーザーエージェントによって実装される可能性のある追加の 安全 制限について論じる。

7.1.4. プライバシーバジェットエポック

サイトは、各プライバシー バジェットエポック （またはエポック）に 記録されたインプレッション を照会するために使用される 別個の差分プライバシーバジェットを受け取る。

このバジェットは、インプレッションに適用される。 それらはユーザーエージェントに登録され、 後で照会されるものであり、 コンバージョンではない。

分析 [PPA-DP] の観点からは、インプレッションの各 エポックは 別個のデータベースを形成する。 有限のプライバシーバジェット が、各データベースに対して行われるすべての照会にわたって強制される。

複数のエポックにまたがるインプレッションから コンバージョン レポートが生成されることは、プライバシー上の帰結を持つ。 ウェブサイトへの単一の訪問が、そのサイトに多くのエポックにわたる活動についての情報を与える可能性がある。 これには、その全期間にわたって コンバージョンサイトが インプレッションの宛先として 識別されていることだけが必要である。 照会できるエポックの数は、ユーザーエージェントによって制限される。

目標は、実現可能な限り大きなエポックを設定することである。 より長い期間は、プライバシーと有用性のより良いバランスを可能にする。 なぜなら、サイトには任意の時点で より大きな全体バジェットを割り当てることができ、 同時に全体的なプライバシー損失率を低く保てるからである。 しかし、より長い間隔は、 プライバシーバジェットを完全に使い尽くしやすくし、 次の更新まで情報が得られなくなることを意味する。

エポック期間を 1 週間に設定する決定は、 おおむね恣意的である。 1 週間は、サイトがプライバシーバジェットをどのように使うかについて、 将来数日または数週間に起こり得る変更を考慮する 綿密な計画なしに、ある程度柔軟に判断できるのに十分であると期待される。

§ 7.2 プライバシーバジェットでは、バジェット処理のプロセスをより詳しく説明する。

7.2. プライバシーバジェット

ブラウザーはプライバシー バジェットを維持する。 これは、プライバシー損失の量を制限する手段である。

この仕様は、その基礎として (ε, δ)-差分プライバシーの個別形式を使用する。 このモデルでは、プライバシー損失は値 ε を用いて測定される。 δ 値は、集約にノイズを追加する際に 集約サービスによって扱われる。

各ユーザーエージェントインスタンスは、 プライバシーバジェットの管理に責任を負う。

要求される各コンバージョンレポートは、 レポートが消費するプライバシーバジェットの量を表す ε 値と、コンバージョンレポートで返され得る値の最大値を指定する。

7.2.1. プライバシーバジェットの差し引き

コンバージョンレポートのためにインプレッションを 検索するとき、 ユーザーエージェントは、それらのインプレッションが保存された プライバシーバジェットエポックのバジェットから 指定された ε 値を差し引く。 そのエポックの プライバシーバジェットが 十分でない場合、 そのエポックのインプレッションは使用されない。

コンバージョン サイトが measureConversion() を呼び出すたびに、 アトリビューション ロジックがインプレッションを選択した エポックについて、 プライバシーバジェットが差し引かれる。

ユーザー エージェントがプライバシーバジェットの枯渇をどのように管理するかは、 選択されたアトリビューション ロジックに依存する。

7.2.2. 安全制限

基本的なプライバシー単位は、 複数のサイトにわたって同じ人物の活動を関連付けることができる攻撃者による 攻撃に対して脆弱である。

サイトのグループは、共有所有権や強い合意がある場合などに、 活動を調整できることがある。 特定の訪問者が同じ人物であることを、FedCM [FEDCM] のようなものを含む 任意の手段で確信できるサイトのグループは、この API から得られた情報を結合できる。

これは、協調が行われるサイト数に比例して、 サイトがアトリビューションから情報を得る速度を 増加させるために使用できる。 既定のプライバシー単位は、 このように公開される情報に制限を課さない。

この効果に対抗するために、ユーザーエージェントは 安全制限を実装できる。 これは、サイトを考慮しない追加のプライバシーバジェットである。 安全制限は、通常の閲覧活動の大部分では到達しないように、 サイトごとのバジェットよりもかなり高く設定される可能性がある。 目標は、それらが集中的な活動または攻撃を受けている場合にのみ 有効になることを保証することである。

サイトごとのプライバシーバジェットと同様に、 サイトがコンバージョンレポートの要求によって 安全制限を超えたかどうかを判定できないことが 重要である。

7.3. 差分プライバシーメカニズム

差分プライバシーメカニズム、すなわちノイズを追加する具体的な方法は、 集約 サービスによって選択できる。

ラプラスノイズを追加することで、良好な結果が得られると期待されており、 ノイズの全体的な大きさと 実装および分析の単純さとのバランスが取れます。 現在の設計では、L1 ノルムに基づく DP 感度を使用しており、 集約時にラプラスノイズを追加することをサポートしています。 他のノイズメカニズムをサポートするには、 感度の計算方法および通知方法に追加の変更が必要になる場合があります。

これらの集約サービスのいずれについても定義されているように、 単一の場所でノイズを追加することで、 レポートの総数が増加しても ノイズの総量が増加しないことが保証される。 これは、レポートが生成される時点で ノイズを適用する差分プライバシー設計 （すなわち、ローカル差分プライバシーモデル） と比べて有用性の面で利点がある。後者では、 ノイズがレポートの総数に比例して増加する。

8. セキュリティ上の考慮事項

8.1. インプレッションストア

Attribution API によって使用されるインプレッションストアは、 閲覧活動に関連する情報を保持し、 閲覧セッションをまたいで永続化する。 インプレッションストアを通じた情報の流れは 厳密に制御されているが、 それはオリジンをまたいで一定量の情報を運ぶ。

次の対策は、インプレッションストアを通じた 有害な情報の流れの可能性を制限する：

• ウェブサイトはインプレッションストアから読み取れない。 インプレッションストアからの情報は、 暗号化されたコンバージョンレポートを通じてのみ公開される。 差分プライバシーは、ユーザーエージェント内の機能と 集約サービス内の機能の組み合わせによって提供され、 集約サービスによって出力される集約情報が 任意のユーザーの寄与が存在しなかった場合の値と 区別可能である確率に対して 厳密な上限を提供する。

• ユーザーは明示的に 保存されたインプレッションを消去できる。

• ユーザーエージェントは、明示的なユーザー操作がない場合でも、 lifetimeDays の最大値を課すことで、 データがインプレッションストアに保持され得る期間を制限することが推奨される。

8.2. 実装におけるサイドチャネルリスク

Attribution API の実装では、必要なセキュリティおよびプライバシー特性を維持するために 注意が必要です。 API を呼び出すサイトは、次の情報を知ることはできません：

• Attribution API が有効であるかどうか。

• アトリビューションが発生したかどうか。

• プライバシー バジェットが枯渇しているかどうか。

• コンバージョンレポートが非ゼロの コンバージョン 値を反映しているかどうか。

• どのhistogramIndexに コンバージョン値が割り当てられているか。

• エポックが開始する 時刻。

明示的な戻り値やスローされた例外だけが、 サイトが Attribution API から情報を得る 唯一の方法ではないことに注意してください。 次のような サイドチャネルから機密情報を推測できる可能性があります：

• API の処理完了にかかる時間の変動。

• メモリ、ストレージ、ネットワーク、CPU など、 API による共有リソースの消費。 これには、その消費量に対する制限の適用が サイトから観測可能な場合、そのような制限の適用も含まれます。

API 内の関数の 実行時間の変動は、 保証を維持するうえでの主要な考慮事項です。 実行時間について特に懸念される要因は 2 つあります：

• measureConversion() が処理する インプレッションの数。 サイトは、保存されるインプレッションの数と それらを選択するロジックを制御できるため、 サイトがサイト間タイミングサイドチャネルを 作成できる重大な余地が生じます。

• 共有グローバル状態へのアクセス。 API への同時アクセスは、 正確性に関するエラーを防ぐため、単一のアトリビューションバジェットロック によって管理されます。 このロックは、API に同時アクセスするサイト間で 情報が漏洩する手段となります。

グローバルプライバシーバジェットストア、 インプレッションサイトクォータストア、 およびエポック開始時刻 にある共有グローバル状態は、 それらの値がアルゴリズムの実行時間に直接影響することはないため、 リスクは比較的小さいです。 それでも実装は、いかなるグローバル状態も フィンガープリント やその他の情報漏洩に寄与しないようにする必要があります。

すべてのサイドチャネルを完全に排除することは現実的ではありませんが、 実装は、Attribution API からの 機密情報の漏洩を防ぐために合理的な努力をしなければなりません。 漏洩を防ぐための戦略には、次のものがあります：

• API が無効になっている場合でも、 すべての API 入力を完全に検証する。

• 条件付きロジックを避ける。たとえば、 measureConversion() は、報告されるコンバージョン値が 0 の場合でも、常にコンバージョンレポートを構築する 完全なプロセスを実行できます。

• 特定の操作に固定の実行時間を設定する。

8.3. 集約サービス

Web プラットフォームの一部ではありませんが、 集約サービスのセキュリティは、Attribution メカニズム全体の セキュリティにとって非常に重要です。 コンバージョンレポートは、 measureConversion()によって生成され、 集約サービスの暗号鍵を使用して暗号化されます。 したがって、これらのレポートに含まれる情報が 開示される可能性の多くは、 集約サービスの詳細に依存します。

ユーザー エージェントの開発者は、Attribution API のサポート対象サービスとして 追加する前に、集約サービスの設計と 集約サービス運用者の信頼性を慎重に検討する必要があります。 これらの問題に関する追加の議論は、 § 6 集約および§ 9 プライバシーに関する 考慮事項にあります。

8.4. 複数サイトからのレポートの結合

Attribution API のプライバシー機構は、 主として サイトの粒度で動作する。 悪意のある運用者は、 複数のサイトについて インプレッションを登録しようとする可能性があり、 その結果、そうでなければアトリビューションを通じて 開示される情報量を超える可能性がある。 § 7.2.2 安全性の制限では、この可能性を軽減するために追加のサイト横断 プライバシーバジェットを設定することについて説明する。

8.5. クロスサイト参加の制御

集約ヒストグラムを生成するには、 複数のサイトが協力する必要がある。 各インプレッションサイトは、 保存するインプレッションについて 一貫した値を生成する必要がある。 コンバージョンサイトは、 正しい値を記録することについてインプレッションサイトを 信頼する必要がある。

API は、集約を汚染し得る望ましくないインプレッションのリスクを サイトが管理するのを助けるために、 多数のフィルタリングオプションを提供する。

• インプレッションサイトは、 conversionSites を使用して、特定のコンバージョンサイトを対象にできる。

• インプレッションは、conversionCallers を使用して、 コンバージョンサイト上で動作する 特定の仲介者に制限できる。

• コンバージョンサイトは、 impressionSites を使用して、アトリビューションの一部として照会する インプレッションサイトを制限できる。

• コンバージョンはまた、impressionCallers を使用して、特定の仲介者によって保存されたインプレッションに 照会を制限できる。

フィルタリングオプションは、 アトリビューションに参加できるサイトを制限するうえで有用であり、 これにより集約結果を汚染できる主体の集合が減少する。 これらのオプションを効果的に使用することは、 望ましくないインプレッションの偶発的な包含を防ぐうえで特に有用である。

これらのフィルタリングオプションは、 結果を汚染しようとする悪意ある試みに対しては 効果が限定的である。 信頼は、これらの制御が想定するほど厳密に二値的であることは稀である。 一覧に含まれるインプレッションサイトは、 コンバージョンサイトの観点から真正なインプレッションと、 偽造または誤ったインプレッションを混在させる可能性がある。 誤ったインプレッションは、Invalid Traffic (IVT) とみなされるものを表し、 その一部は不正と見なされる可能性がある。

8.5.1. 広告不正

ウェブ上の広告は、 さまざまな種類の不正の対象となってきた。 サイトは、この API を使用してインプレッション不正を行い、 自分たちに配置された広告に価値が誤って帰属されたという印象を 作り出そうとする可能性がある。

インプレッションの不正登録は、この API において特に懸念される。 なぜなら、インプレッションはデバイス上にのみ保存されるからである。 不正なインプレッションを識別してアトリビューションから除外するために サーバー側の知能を適用することはできない。

悪意あるインプレッションに対する唯一の直接的な緩和策は、 サイトレベルのフィルタリングオプションである。 これにより、完全に信頼されていないサイト上のインプレッションが、 意図された候補インプレッション集合へのアトリビューションを妨害することを防ぐ。

逆に、コンバージョンレポートは暗号化されているにもかかわらず、 レポートはコンバージョンサイトに送信されるため、 コンバージョンサイトは、そのコンバージョンが不正である可能性が高いと判断し、 それを集約から除外できる。

9. プライバシー上の考慮事項

この API の主なプライバシー目標は、 サイトにアトリビューションを実行する能力を提供しても、 それらのサイトがクロスサイト認識を行う能力を 向上させないことを保証することである。

このセクションは、この目標を達成するために必要な保護について より多くの情報を提供する。 追加の議論では、同一サイト認識の防止など、 副次的なプライバシー目標について述べる。

9.1. Attribution API によって公開される情報

インプレッションストアと プライバシーバジェット ストアは、 閲覧活動の横断的な情報を含む。 API の使用が増えるにつれて、 この情報の範囲も広がる。 しかし、これらのストアに書き込まれる情報のほとんどは 決して開示されない。 アトリビューションはデバイス上で実行されるため （オンデバイスアトリビューション）、 帰属されたコンバージョンに関する情報のみが Attribution API によって公開される。これは、 インプレッションとコンバージョンの両方に関する情報が オフデバイスアトリビューションのために 集約サービスへ送信される他の方式とは対照的である。 後者の方式では、集約サービスの侵害 （または集約サービスとの通信の侵害）によって 明らかになり得る情報量が 著しく大きい。

Attribution API がアトリビューションを行うとき、そのアトリビューションに関する情報は、 差分プライバシー制限が許す範囲でのみ デバイスから公開される。

Attribution API は、比較的まれなコンバージョンイベントと、 関連する限定されたインプレッション候補集合との関連を測定することを意図しているが、 より大規模なデータ収集のために API が悪用される可能性を 考慮することが重要である。 インプレッションが可能なコンバージョン サイトを列挙する（およびその逆）という要件は、 API の大量データ収集への悪用を防ぎ、 そのような悪用の試みをより可視化するうえで重要な役割を持つ。

9.2. Attribution API の無効化

ユーザーエージェントは、ユーザーが Attribution API を無効にするための コントロールを提供しなければならない。

Attribution API は、 集約された情報のみを明らかにするよう設計されている。 差分プライバシーを使用することで、 特定のユーザーが集約された出力に 寄与したかどうかを特定できる可能性が制限される。 ただし、一部のユーザーは依然として アトリビューション測定への参加を望まない可能性がある。

実装は、Attribution API 専用のコントロールを使用するか、 複数の機能に適用される統合されたプライバシーコントロールを通じて、 ユーザーにオプトアウトする選択肢を提供できる。

ユーザーエージェントの開発者には、他のプライバシーモードと Attribution API との相互作用を考慮することが推奨される。 たとえば、プライベートブラウジングモードではアトリビューションを無効にしたり、 ユーザーが診断データの収集をオプトアウトしている場合には 無効にしたりすることができる。

設計上、ユーザーがオプトアウトしているかどうかをウェブサイトが検出することはできない。

フィンガープリンティングのリスクを最小限に抑え、 Attribution API を無効にすることを選択したユーザーに対する 差別を防止するため、 サイトは API が無効になっていることを検出できてはならない。 具体的には、Attribution API に対するすべての呼び出しは、 それ以外の点で有効である場合、 API が無効になっていても正常に完了する。 動作上の唯一の違いは、 API が無効になっているときに返されるコンバージョン レポートでは、 コンバージョン値が決して報告されないことである。 レポートは暗号化されているため、 この違いを、コンバージョンレポートを受信する サイトが検出することはできない。

9.3. 可視性

実装は、インプレッションストアの状態を確認し、 過去に送信されたレポートを確認する方法をユーザーに提供することが推奨される。

これらのインターフェイスは、 サイトによる Attribution API の集約的な使用を示す 要約情報に限定される場合がある。 インプレッションおよび送信されたレポートの詳細を調べるインターフェイスは、 ユーザーとウェブ開発者の双方による API の動作診断を可能にする可能性がある。

9.4. 未構成のブラウザー

この API は、ユーザーエージェントのインスタンスが、 measureConversion() の要求に応答するために 必要なすべての設定を 備えていることを前提としている。

集約 サービスの設定のうち、 measureConversion() を呼び出すために必要なものが 存在しないか古くなっている場合、 そのことをサイトが観測できる可能性がある。

設定の取得によって measureConversion() の呼び出しの解決が遅延する可能性がある場合、 タイミングサイドチャネルが生じる。 代わりに偽の応答を生成すると、 適切に設定されたユーザーエージェントからの応答と 偽の応答との違いを 観測できる可能性がある。 これにはキー識別子や その他の暗号化されていないメタデータが利用される可能性がある。 暗号文の長さの違いによって、暗号化される内容の変更や アルゴリズムの選択の変更が明らかになる可能性もある。

古い設定または存在しない設定を検出することは、 フィンガープリントを取得するためにユーザーエージェントに対して使用される可能性がある。 HPKE 設定はオンデマンドで取得してはならない。 その取得に要する時間によって、 measureConversion() の呼び出し元に情報が漏洩するためである。

したがって、ユーザー エージェントは、 サイトから観測できない方法で 集約サービスの設定の取得を 優先することが推奨される。 これは、起動時に、 コンテンツの読み込みを開始する前に設定を取得することで実現できる可能性がある。

必要な設定を取得できない場合、 または明らかに古い場合、 実装は measureConversion() が呼び出されたときに 直ちに拒否することを選択してもよい。 これによって情報は漏洩するが、 偽の値を生成しようとする場合よりも漏洩量が少なくなる可能性がある。

9.5. 保存されたインプレッションに識別情報を含めること

サイトは、 matchValue または他のフィールドを使用して、 インプレッション内に一定量のデータを符号化できる。 API は、サイトがこれらのフィールドにユーザー識別子を符号化することを 防止しない。 アトリビューションプロセスは、 コンバージョンレポートを構築する際に このデータを使用でき、 これは、その識別情報が そのレポートを受け取るサイトに利用可能になるリスクを含意する。 次の対策はこのリスクを緩和する：

• インプレッション ストアは直接読み取ることができない。 したがって、識別子は、それらに関する情報が コンバージョンレポートで明らかにされる範囲でのみ トラッキングに使用可能である。

• コンバージョンレポート内の情報は、 集約およびノイズの追加の後にのみ公開される。

• ユーザーはインプレッションストアを消去する能力を持つ。

• Attribution API が無効である場合、 インプレッションはインプレッションストアに保存されない。

9.6. 第三者コンテキストでの使用

Attribution API は、サードパーティコンテキストでも利用できる。 特に、サードパーティ iframe は してもよい、saveImpression() を呼び出すことを。 ただし、インプレッションはサイト のトップレベルナビゲーションコンテキストに記録され、iframe のオリジンには 記録されないことに注意されたい。

第三者コンテキストで API が利用可能であることは、 プライバシーリスクをいくらか増加させるが、 iframe は広告を表示するために一般的に使用されるため、 このサポートは必要と見なされる。

9.7. API 状態の消去

ユーザー エージェントは、ストレージを消去するオプションを提示する場合がある。 これらは 2 つの理由で存在する：

• サイトに対するプライバシー。 これにより、サイトは将来の相互作用でユーザーを認識できない （すなわち、同一サイト認識を防止する）。

• 活動の痕跡をローカルに削除すること。 これにより、コンピューターの他のユーザーが 閲覧履歴にアクセスできなくなる。

プライバシーバジェット消費を追跡する状態を消去することは、 サイトに対するプライバシーに悪影響を及ぼす。 そうすると、サイトはアトリビューションから より多くの情報を得ることができるようになる。

ユーザー エージェントはしてもよい、データを プライバシー バジェットストアおよびエポック開始時刻から、 API が無効化されたときに消去することを。 その場合、API が再び有効化されると、 API が無効化される前に どのバジェットが消費されたかを判断する方法はない。 その場合、ユーザーエージェントは、 最後の閲覧履歴消去の値を更新して、 プライバシー バジェットが意図せず超過しないようにすることができる。

9.7.1. サイトデータの消去

ユーザーの要求により サイトデータを消去するが、 閲覧履歴は保持する場合、 ユーザー エージェントは、影響を受けるサイトの 集合、 false（forgetVisits 用）、 および操作が行われた時刻を与えて、 clear browsing history for attribution を呼び出す。 これはそのサイトのプライバシーバジェットをゼロに設定し、 そのサイトでのコンバージョン測定の使用を防止する。 これはインプレッションストアから保存されたインプレッションを削除しない； 論理的には、インプレッションは保存された時点で コンバージョンサイトへ転送される。

サイトの要求により、 `Clear-Site-Data` ヘッダーの使用を通じて サイトデータを消去する場合、 ユーザー エージェントは、プライバシーバジェットストア またはエポック開始 時刻のいずれも変更せず、 インプレッションを削除するだけである。

9.7.2. 閲覧履歴の消去

閲覧履歴を消去する場合、 プライバシー バジェットストアを更新するだけでは不十分である。 サイトに対するプライバシー損失を防ぐために必要な サイトごとの 情報を保持すると、 コンピューターの他のユーザーが発見できる サイト訪問に関する情報が残る。

閲覧履歴を消去するユーザーエージェントは、 影響を受けるサイトの 集合、 true（forgetVisits 用）、 および操作が開始された時刻を与えて、 clear browsing history for attribution を呼び出す。

閲覧履歴を消去するとき、 ユーザー エージェントは、 サイトごとのすべてのプライバシーバジェット情報を 削除する必要がある （つまり、プライバシーバジェットストアからエントリーを削除する）。 ユーザー エージェントはまた、 その情報を失った結果として、 その後の任意のプライバシー バジェット消費が 構成された制限を超えるプライバシー損失を引き起こせないようにする必要がある。

これは、閲覧履歴が破棄された エポック についてアトリビューションを無効化することで達成できる。 そうしない場合、履歴の消去の直前に そのバジェットを消費したサイトは、 状態の消去がなければ API を通じて学習できた量を超えて 学習できることになる。

これは、影響を受けるサイトについて、そのエポックの残りの期間 API を無効化する。 エポック開始 時刻は消去されないため、 エポック タイムラインは連続したままである。

ユーザー エージェントは、 last browsing history clear 値において 履歴が最後に消去された時刻を記憶する。 これは、サイトが ユーザー エージェントが選択した最大許可プライバシーバジェットを超過できないことが保証されるまで、 バジェット消費を防ぐために使用される。

get the starting epoch for attribution アルゴリズムは、 コンバージョン サイトが、 状態が消去された時点から 1 エポック 期間内に 開始する任意のエポックからの インプレッションを 照会できないことを保証する。

9.7.3. インプレッションの消去

インプレッションストアを消去するための仕組みを提供しなければならない。 たとえば、Attribution API を 無効化するコントロールが作動したときに、 インプレッションストアを消去できる。

ユーザーエージェントが提供する、保存されたデータ （履歴、Cookie など）を消去するためのあらゆる仕組みを、 インプレッションストアも対象とするよう拡張することが推奨される。 § 9.7 API 状態の消去では、保存されたデータの消去について より詳細な情報を提供する。

サイトの状態を消去するユーザー エージェントは、 影響を受ける期間中に保存されたすべての保存済みインプレッションのうち、 インプレッションサイトまたは コンバージョンサイトが一致するものを破棄しなければならない。 インプレッションサイトについては、 これらのインプレッションは、 消去されたアクティビティに関連する。 状態が消去されたコンバージョンサイトは、 これらのインプレッションを使用できなくなる。

インプレッションのうち、仲介サイトが一致するものは、 保持できる。

9.8. 時計の選択

この API は、時刻の基礎として 壁時計を使用する。 これは主に、API が永続的な時間の概念に依存するためである。 単調時計は、 ユーザー エージェントの単一実行中にのみ定義されるため、 ユーザーエージェントが再起動された場合の 一貫性は保証されない。

壁時計は、 クロックドリフトにより蓄積する可能性のある誤差を補正するために調整できる。 したがって、壁時計は、 常に一定の速度で進むことを保証されず、 時には減少する可能性も含む。

壁時計の減少は、 この API が提供するプライバシー保証に影響しない。 時計の増加だけが、 プライバシーに悪影響を及ぼし得る。 通常の時間の進行を上回る増加は、 プライバシーバジェットが意図よりも早く 更新される結果をもたらす可能性がある。

各エポック内で補正が行われる時計については、 時計調整はプライバシーに影響しない。 十分に大きな単一の補正は、 プライバシー バジェットが予定より早く更新され、 一回限りのプライバシー損失の増加をもたらす可能性がある。 継続的な大きな補正はプライバシーに最も深刻な影響を与える。 なぜなら、各エポック間の遷移ごとに 追加のプライバシーバジェットが公開されるためである。

時間が非常に大きく増加して エポック全体を飛び越える場合でも、 追加のプライバシー損失は生じない。 インプレッションを 保存できない限り、 プライバシー損失は起こり得ない。

もちろん、時計に対して大きな、または継続的な補正を必要とする 任意のユーザーエージェントは、 それが報告する時刻の結果として、 高度に識別可能である可能性が高い。 それだけで、望ましくないクロスサイト認識を可能にするには十分である可能性が高い。

10. 謝辞

この仕様は、多くの人々による多大な作業の結果である。 このレベルの API の大まかな形は、Luke Winstrom のアイデアに基づいている。 プライバシーアーキテクチャは、[PPA-DP] の著者たちによるものである。