1. 導入
この文書は、集約された差分プライバシー付きメトリクスの収集を可能にする、 ブラウザー向けの API を定義する。
この API の目標は、広告のアトリビューションを可能にすることである。
1.1. Attribution
広告における attribution とは、関心対象の結果に先行する行動を 識別し、それらの行動に価値を割り当てる処理である。
広告主が関心を持つ行動は、 主に広告の表示 (インプレッションとも呼ばれる)である。 その他の行動には、広告クリック(またはその他のインタラクション)や、 利用されなかった広告表示の機会が含まれる。
広告における望ましい結果は、 広告主が広告表示を通じて改善しようとする任意の結果を含むため、 より多様である。 望ましい結果は コンバージョンとも呼ばれることがあり、 これは潜在顧客を顧客へと「転換」することを指す。 コンバージョンに該当するものには、 販売、購読、ページ訪問、問い合わせなどが含まれ得る。
この API では、行動と結果はいずれも イベント、すなわち一度だけ発生する物事である。 広告における attribution に特有なのは、 これらのイベントが同じサイト上で発生しない場合があることである。 広告は、広告主のサイト以外のサイトで表示されることが最も多い。
attribution における主な課題は、プライバシーを維持することである。 Attribution は異なるサイト上の活動を結び付ける。 attribution の目標は、コンバージョンが発生する前に同じ人物に表示された インプレッションを見つけることである。
attribution 情報が直接明らかにされた場合、 望ましくない コンテキスト横断認識を可能にし、 それによりトラッキングを可能にする。
この文書は、attribution 情報が集計サービスを用いて集計されることを保証することで、 コンテキスト横断認識を回避する。 集計サービスは、各人物がその集計に寄与した値を明らかにすることなく 集計を計算すると信頼される。
各ブラウザーインスタンスが特定のサイトの集計に寄与する情報量には 厳格な制限が設けられる。 差分プライバシーは、各寄与に追加のプライバシー保護を提供するために用いられる。
集計サービスの動作の詳細は § 7 集計 に含まれる。 使用される差分プライバシー設計は § 8 差分プライバシー で概説される。
1.2. 背景
Web の初期から、 広告はサイト作成を財政的に支援するため広く用いられてきた。
Web を他の広告媒体と区別する特徴の一つは、 広告キャンペーンの効果に関する情報を取得できることであった。
Web 広告主は、リーチ(広告を見た人数)、 フリークエンシー(各人が広告を見た頻度)、 およびコンバージョン(広告を見た人のうち、 その後その広告が促そうとしていた行動を取った人数)といった主要なメトリクスを測定できた。 比較すると、これらの測定は他のどの媒体よりもはるかに迅速かつ正確であった。
測定性能の代償はプライバシーであった。 正確で包括的な情報を生成するために、 広告事業者はすべての Web ユーザーの活動を広範に追跡した。 各ブラウザーには追跡識別子が与えられ、 多くの場合、サイト横断コンテンツにより記録される Cookie が用いられた。 関心対象のすべての行動がこの識別子に対して記録され、 個人のオンライン活動に関する包括的な記録が形成された。
個人の行動に関する詳細な記録を持つことで、広告主は人々の特徴を推論できた。 それらの特徴により、広告に適したオーディエンスを選びやすくなり、 その効果が大幅に向上した。 これにより、より多くの情報を収集する強い動機が生じた。
オンライン広告は非常に競争が激しい。 広告を表示するサイトは、各広告枠からできるだけ多くの収益を得ようとする。 広告主は、費用に対して最も効果がある場所に広告を掲載しようとする。 これらの主体—およびその代理として活動する仲介者—が得る競争上の優位性は、 潜在的なオーディエンスについてより包括的な情報を持つことに依存する。
時間の経過とともに、関心対象の行動はオンライン活動のほぼあらゆる側面を含むように拡大した。 その情報を Web 外の活動と相関させる方法が考案された。 活発な取引が形成され、 さまざまな目的で取引される個人情報を扱う複数の業者が存在するようになった。
1.3. 目標
この文書の目標は、トラッキングを可能にしない形で広告の attributionを実行する手段を定義することである。
1.4. エンドユーザーの利益
広告パフォーマンスの測定は、サイト横断の新たな情報フローを作り出す。 その情報フローは、コンテキスト横断認識というプライバシーリスクまたはコストを生じさせるため、 エンドユーザーに対する利益の観点から正当化される必要がある。
attributionの使用を通じてエンドユーザーが得る利益は間接的である。
Web サイトを訪問するエンドユーザーは、 そのサイトが表示する広告に対する主として自らの注意を通じて、 「無料」のコンテンツまたはサービスの代価を支払う。 この「価値」は広告主に生じ、 広告主はその対価としてサイトに支払う。 サイトはこの資金を、 コンテンツまたはサービスの提供を支援するために使用することが期待される。
attribution 測定システムへの参加は、 Web ユーザーにとって二次的なコストを構成する。
attribution のサポートは、 主としてどの広告がどのような状況で最も効果を発揮するかを広告主に知らせることにより、 より効果的な広告を可能にする。 そのような状況には、 広告が表示された時刻と場所、 広告が提示された人物、 そして広告自体の詳細が含まれ得る。
その情報を結果に結び付けることで、 広告主は、自らが最も重視する結果に最も頻繁につながる状況を知ることができる。 これにより、広告主は効果的な広告により多く支出し、 効果の低い広告への支出を減らすことができる。 これにより、得られる価値に対する広告の総費用が低下する。 [ONLINE-ADVERTISING]
コンテンツ出版社やサービス提供者など、広告在庫を提供するサイトは、 より効率的な広告から間接的に利益を得る。 広告主が求める結果につながる広告をより適切に表示できる広告媒体は、 広告枠に対してより高い料金を請求できる。
広告の掲載を通じて支援を得るサイトは、 質の高いコンテンツまたはサービスをよりよく提供できる。 重要なのは、その支援がオーディエンスから不均等に得られることである。 これは、他の形態の財政的支援よりも公平であり得る。 広告対象の商品に支出する傾向または能力が低い人々も、 支払う余裕のある人々と同じ広告支援型コンテンツおよびサービスを利用できる。 [EU-AD][COPPACALYPSE]
広告に支えられた「無料」サービスを提供する能力には、 それらのサービスの価値に由来する測定可能な経済的利益がある。 [FREE-GDP]
1.5. 集合的プライバシー効果
集計の使用は、適切に実装されている場合、サイトに提供される情報が個人ではなくグループに関するものとなることを保証する。
したがって、この機構の導入は、集合的プライバシーの考え方に沿った、集合的意思決定を表す。
attribution 測定への参加は、 参加するグループが大きいほどプライバシーコストが低くなる。 これは、集計が、 サイトが集計から個人に関する情報を抽出する能力に与える影響による。 これは特に、この仕様で使用されるプライバシー設計の数学的基盤である 中央型差分プライバシーに当てはまる。
参加者のより大きなコホートは、測定されている広告について、 より代表性が高く、したがってより有用な統計も生成する。
attribution が正当化される場合、 これら二つの要因はいずれも、すべてのユーザーに対して attribution を有効にする動機となる。
ユーザーエージェントが attribution 測定を有効にすることは、 一部の人々には好意的に受け止められない。 広告に関与することで生じるコストと利益の受け止め方は、人によって異なる。 提案されている設計では、人々がその選択をサイトに明らかにすることなく attribution に参加しているように見せる選択肢を可能にしている。§ 10.2 Attribution API の無効化を参照。
1.6. ヒストグラムを用いた Attribution
Attribution は、 一つ以上の広告掲載(インプレッション)と、 広告主が望む結果との相関を測定しようとする。
集計として考える場合、 個人に関する情報は有用ではない。 行動と結果はグループ化される必要がある。
attribution の最も単純な形式は、 広告の属性に従ってインプレッションをいくつかのグループに分割し、 コンバージョン数を数える。 グループは、広告が表示された場所、 表示された内容(「クリエイティブ」)、 広告が表示された時刻、 または誰に表示されたかといった属性から形成され得る。
これらのグループ化と、 それぞれに attribution されたコンバージョンの集計が ヒストグラムを形成する。 ヒストグラムの各バケットは、 広告グループのコンバージョンを数える。
異なる目的には異なるグループ化が用いられ得る。 たとえば、クリエイティブ(広告の内容)によるグループ化は、 どのクリエイティブが最も効果的かを知るために用いられ得る。
各コンバージョンで 1 より大きい値を追加すると、 単なる件数以上のものが可能になる。 ヒストグラムは値も集計でき、 これは異なる結果を区別するために用いられ得る。 インプレッションに割り当てられる値は、 コンバージョン 値と呼ばれる。 より高いコンバージョン値は、より大きな購入や、 より高く評価される任意の結果に用いられ得る。 コンバージョン値は、信用を分割するために複数のインプレッション間で分割されることもある。
2. 動作の概要
Attribution API は、 インプレッションとコンバージョンという二つのイベントクラス間の関連について、 集計情報を提供する。
インプレッションとは、 広告主が任意の Web サイト上で行う任意の行動である。 API は、何をインプレッションとして記録できるかを制約しない。 広告主が測定しようとする典型的な行動には、次のものが含まれる。
-
広告を表示すること。
-
ユーザーが何らかの方法で広告とインタラクションすること。
-
広告を表示しないこと(特に、広告キャンペーンが有効かどうかを確認しようとする対照実験の場合)。
API において、コンバージョンは、 測定対象となる結果である。 API は、何が結果と見なされ得るかを制約しない。 広告主が測定しようとする典型的な結果には、次のものが含まれる。
-
購入すること。
-
アカウントに登録すること。
-
Web ページを訪問すること。
この節の残りでは、 Attribution API が集計サービスと連携して 集計 attribution 測定を生成する方法を説明する。 その動作は次の図に示される。
インプレッションが発生すると、 saveImpression() メソッドを使用して、 ブラウザーに情報の保存を要求できる。 これには、インプレッションの識別子と、 インプレッションについての追加情報が含まれる。 たとえば、広告主は追加情報を使用して、 インプレッションが広告ビューであったか広告クリックであったかを記録する可能性がある。
コンバージョン時に、コンバージョンレポートが 作成される。 コンバージョンレポートは、 ブラウザーが以前に保存した任意のインプレッションからの情報を含む、 暗号化されたヒストグラム寄与である。
measureConversion() メソッドは、 コンバージョンレポートを構築する方法をブラウザーに伝えるために使用される、 制限付きクエリを受け入れる。 これには、ブラウザーが保存したインプレッションから選択する値、 選択されたインプレッションに割り当てられるコンバージョン値、 およびコンバージョンレポートを構築するために必要なその他の情報が含まれる。
コンバージョンレポートにより作成されるヒストグラムは、次のように構築される。
-
クエリがインプレッションを見つけなかった場合、 またはサイトのプライバシー 予算が使い果たされている場合、 すべてがゼロ(0)からなるヒストグラムが構築される。
-
一致するインプレッションが一つ以上見つかった場合、ブラウザーは last-n-touch attribution ロジックを実行して関連するインプレッションを選択する。提供されたコンバージョン 値は、attribution されたインプレッション時に指定されたバケットのヒストグラムに追加される。 その他すべてのバケットはゼロに設定される。
ブラウザーは、報告されたコンバージョンを反映するようにプライバシー予算ストアを更新する。
結果のヒストグラムは、選択された集計サービスの要件に従って集計用に準備され、サイトに返される。 これには少なくともヒストグラムの暗号化が含まれる。
この API を呼び出すサイトは、常に有効なコンバージョンレポートを受け取る。 その結果、サイトはこのインタラクションから他のサイトで何が起きたかについて何も知ることがない。
サイトは、この API の呼び出しから受け取る暗号化されたヒストグラムを収集し、 それらを集計サービスに提出できる。
サイトから暗号化されたヒストグラムの集合を受け取ると、集計サービスは次を行う。
-
提供された入力から以前に集計を計算しておらず、 十分な数のコンバージョンレポートがあることを確認する、
-
十分なノイズを含めてヒストグラムを加算し、 差分プライバシー付きの集計ヒストグラムを生成する、そして
-
集計をサイトに返す。
最終出力を attribution result と呼ぶ。
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 コンバージョンに対する Attribution の要求)
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));
ユーザーエージェントがその URL をサポートし、
かつそれが優先サービスの一つを含む場合、
最初の優先サービスが serviceUrl という名前の変数に保存される。
それ以外の場合、serviceUrl は undefined のままとなる。
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 は、
異なる集計サービスで使用される提出プロトコルを記述する。
この文書は二つのプロトコルを定義する。
dap-18-histogram- MPC を使用する DAP ベースのプロトコル [DAP]。§ 7.1 マルチパーティ 計算集約を参照。
3.4. インプレッションの保存
saveImpression() メソッドは、 ユーザーエージェントに、インプレッションをインプレッションストアに記録するよう要求する。
この場合、サイトはインプレッションを直接保存し、
広告主(advertiser.example)を識別し、
広告主によって取り決められた情報を含める。
次の例では、
これには、広告主が後でこの広告を選択するために使用する可能性のある
matchValue
値(2)、
attribution された値を含める先のヒストグラムのインデックス(histogramIndex
= 3)、
および広告主が必要とする期間以上の保持期間(lifetimeDays
= 7)
が含まれる。
navigator. attribution. saveImpression({ histogramIndex: 3 , matchValue: 2 , conversionSites: [ "advertiser.example" ], lifetimeDays: 7 , });
あるいは、Supply-Side Platform(SSP)や Demand-Side Platform(DSP)などの仲介者が、 iframe から同じ API を呼び出す場合がある。 フレームから同じ API 呼び出しを行うと、 仲介サイトの識別子がインプレッションとともに保存される。
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- インプレッションに関連付けられた任意のメタデータ片。この値は、 どのインプレッションがコンバージョンから attribution を受け得るかを識別するために使用できる。
conversionSites, 型は sequence<USVString>、デフォルトは[]- このインプレッションに対するコンバージョンが 発生し得るトップレベルのコンバージョン サイトであり、 それらのドメイン名によって識別される。 measureConversion() メソッドは、 示されたサイトの一つによって呼び出された場合にのみ、このインプレッションに attribution する。 空の場合、任意のコンバージョン サイトが一致する。
conversionCallers, 型は sequence<USVString>、 デフォルトは[]- このインプレッションをコンバージョンのために 選択できる仲介サイトまたはコンバージョンサイトであり、 それらのドメイン名によって識別される。 measureConversion() メソッドは、 示されたサイトの一つによって呼び出された場合にのみ、このインプレッションに attribution する。 このオプションには、コンバージョンサイトと仲介サイトの両方が含まれる。 空の場合、API を呼び出す任意のサイトが一致する。
lifetimeDays, 型は unsigned long、デフォルトは30- 正の「有効期間」(日数)であり、その経過後はインプレッションが attribution を受けられなくなる。 ユーザーエージェントは有効期間に上限を課すべきであり、 ここで指定された値がその上限を超える場合は、その値を黙って減らすべきである。
priority, 型は long、デフォルトは0- attribution 中にインプレッションをソートするために使用される整数。
3.5. コンバージョンに対する Attribution の要求
measureConversion() メソッドは、 ユーザーエージェントに、コンバージョンに対してattributionを実行し、 コンバージョン レポートを返すよう要求する。
measureConversion() メソッドは、 一致するインプレッションが見つかるかどうかに関係なく、 常にコンバージョンレポートを返す。 一致がない場合、または差分プライバシーが attribution の報告を許可しない場合、返されるコンバージョンレポートは ヒストグラムに寄与しない、すなわち一様にゼロとなる。
暗号化された測定の作成を要求するために、
サイトは measureConversion()
メソッドを呼び出す。
この関数は四つの異なる種類の入力を受け取る。
-
選択された集計サービス。 これは URL を使用して識別される。 集計サービスを選択するための例の手順は、 ブラウザーがサポートするサービスを選択する方法を示している。
const serviceDetails= { aggregationService: serviceUrl, }; -
集計測定の詳細。 これらの値は、複数のブラウザーにわたる API のすべての呼び出しで一貫している。 これには、ヒストグラムのサイズと、 費やされる可能性のあるプライバシー予算の量が含まれる。
const aggregatedMeasurementDetails= { histogramSize: 20 , epsilon: 1 , }; -
考慮するインプレッションを選択する、 すべて任意の属性の集合。 これには、インプレッションがどれだけ古くてもよいか (
lookbackDays)、 インプレッションを保存した可能性のあるインプレッション サイト (impressionSites)、 インプレッションを保存した可能性のある仲介サイト (impressionCallers)、 およびmatchValuesの選択が含まれる。const selectionDetails= { lookbackDays: 14 , impressionSites: [ "publisher.example" , "other.example" ], impressionCallers: [ "ad-tech.example" ], matchValues: [ 2 ], }; -
attribution ロジックのパラメーター。
const attributionDetails= { // top impression's histogram index gets 50% of value, the next two 25% each credit: [ .5 , .25 , .25 ], value: 3 , maxValue: 7 , };
これらの値が決定されたら、 サイトは API を呼び出して、暗号化されたコンバージョンレポートを取得する。
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 を呼び出した可能性のある、 インプレッションサイトと 仲介 サイトの両方を含むサイトの集合。 空でない場合、 一覧にあるサイトの一つによって記録されたインプレッションのみが、 このコンバージョンと一致する資格を持つ。
credit, 型は sequence<double>- 数値のリスト。
value, 型は unsigned long、デフォルトは1- コンバージョン 値。attribution が行われ、プライバシー 制限が満たされる場合、この値はコンバージョンレポートにエンコードされる。
maxValue, 型は unsigned long、デフォルトは1- 集計に含まれるすべての寄与にわたる最大のコンバージョン 値。 epsilon とともに、これは結果に追加されるランダムノイズの分布を較正するために使用される。 また、このコンバージョンレポートに費やすプライバシー予算の量を 決定するためにも使用される。
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. 内容
インプレッションストアは、 集合であり、インプレッションからなる。
| Match Value: | saveImpression() に渡された
matchValue。
|
|---|---|
| Impression Site: | saveImpression() が呼び出された インプレッション サイト。 |
| Intermediary Site: | saveImpression() を呼び出した仲介サイト、
または API がインプレッションサイトによって呼び出された場合は
undefined。
|
| Conversion Sites: | saveImpression() に渡された コンバージョンサイトの集合。 |
| Conversion Callers: | measureConversion() を呼び出す際に、 このインプレッションを選択できるサイト、すなわち コンバージョンサイトまたは仲介サイトの集合。 |
| タイムスタンプ: | saveImpression() が呼び出された時刻。 |
| 有効期間: | インプレッションが attribution の対象として残る期間。saveImpression() の呼び出しによるもの、 またはユーザーエージェント定義の制限によるもの。 |
| Histogram Index: | saveImpression() に渡されたヒストグラムインデックス。 |
| 優先度: | attribution 中にインプレッションをソートするために使用される整数。 |
4.1.2. 保守
ユーザー エージェントは、 タイムスタンプおよび 有効期間の値を 定期的に使用し、インプレッションストア内の、期限切れとなったインプレッションを識別して削除すべきである。
measureConversion() が、期限切れのインプレッションを attributionから 除外する限り、 インプレッションを期限切れと同時に削除する必要はない。 しかし、 ユーザー エージェントは期限切れのインプレッションを無期限に保持すべきではない。
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 を渡す。
-
origin がタプルオリジンでない場合、戻る。
-
origin のhost 部分を渡して、 登録可能ドメインを取得するを呼び出すことで返される値を site とする。
-
インプレッション ストアの各インプレッション impression について反復する。
-
impression のIntermediary Site が
undefinedであり、 そのImpression Site が site と等しい場合、 remove impression from the インプレッションストア and continue. -
impression が site と等しいIntermediary Siteを持つ場合、 remove impression from the インプレッションストア and continue.
-
impression のConversion Sites が site を含む場合:
-
impression のConversion Sitesから site を削除する。
-
impression のConversion Sites が空である場合、 impression をインプレッションストアから削除して、 continue。
-
-
impression のConversion Callers が site を含む場合:
-
impression のConversion Callersから site を削除する。
-
impression のConversion Callers が空である場合、 impression をインプレッションストアから削除して、 continue。
-
-
この処理は、 空の集合のConversion Sitesで保存されたインプレッションを削除しない。
4.1.4. サイト名
インプレッションストアは、 三種類のサイトに関する情報を保存する。 インプレッションサイト、 任意の仲介サイト、 およびコンバージョンサイトの集合である。
これらのサイトはすべて、
"https" のスキームを持つ
scheme-and-host 形式でなければならない。
これは、hostの
単純な文字列シリアライズが、サイトを識別するのに十分であることを意味する。
したがって API は、単純な文字列を使用して
サイトを表すことができる。
実装が内部的に、タプルのhost 部分だけを使用してサイトを表すことも可能である。
-
host を、input を渡してホストパーサーを呼び出すことにより返される値とする。
-
host が failure である場合、failure を返す。
-
site を、host を渡して登録可能ドメインを取得するにより返される値とする。
-
site が null である場合、failure を返す。
-
site が "
localhost" である場合、または site が ".localhost" で終わる場合、 failure を返す。 -
("
https", site) のscheme-and-host タプルを返す。
このアルゴリズムは、登録可能ドメインよりも多くの
ドメインラベルを含む文字列からも、
site を正常に生成する。
たとえば、"extra.example.com" は "example.com" として解析される。
このアルゴリズムは localhost ドメイン [RFC6761] を受け入れない。 そのため、サイト名の抽出に依存する任意のアルゴリズムは、 localhost ドメインが言及された場合、 または現在のサイト(トップレベルまたはフレーム内)が localhost ドメインである場合に失敗する。 これは、テストおよび開発にローカルサーバーを使用することを困難にする可能性がある。 実装は、テストおよび開発を支援するために localhost チェックを無効化する設定を提供してもよい。
4.2. プライバシー予算管理のための状態
ユーザー エージェントは、 プライバシー予算の消費を管理するために使用される、いくつかの状態を維持する。
-
プライバシー 予算ストアは、 サイトごとおよびエポックごとの プライバシー予算の状態を記録する。
-
グローバルプライバシー予算ストアは、 すべてのサイトにまたがって適用される、 エポックごとのグローバルプライバシー予算の状態を記録する。
-
インプレッションサイトクォータストアは、 グローバルプライバシー予算ストアから消費するための、 インプレッション サイトごとおよびエポックごとのクォータの状態を記録する。
-
エポック開始 時刻は、エポックがいつ開始するかを決定するために使用される。 この値は、 measureConversion() の呼び出しの副作用として初期化される。
-
単一のattribution budget lock は真偽値フラグであり、 プライバシー予算ストアに対する同時操作を防ぐために使用される。 そうしないと、予算の過剰消費につながる可能性がある。
プライバシー予算 ストア、グローバルプライバシー予算ストア、 およびインプレッションサイトクォータストアは、 プライバシーおよび安全予算を控除するによって更新される。
インプレッション ストアと同様に、 プライバシー予算 ストアおよび関連ストアはストレージキーを使用しない。 これらのストアには、情報の消去方法に関する追加の制約がある。 詳細は § 10.7 API 状態の消去 を参照。
attribution budget lock を真偽値フラグとして定義する選択は、 仕様上の便宜によるものである。 実装には代替構造の方が適している可能性がある。 実装は、競合の範囲を狭めるために、 エポックごとなどにこの値を分割できる可能性がある。
4.2.1. プライバシー予算ストア
プライバシー予算キーは、 次の項目からなるタプルである。
- エポックインデックス
- サイト
プライバシー予算 ストアは、キーが プライバシー予算キーであり、 値が32 ビット符号なし整数であるマップである。 これらの整数は、 microepsilon単位の値を格納する。 microepsilonは、 差分プライバシー [DP] で使用される 単位 epsilon 値の 100 万分の 1 である。
32 ビット整数の選択は、epsilon の設定を 最大 epsilon 4294 以下に制限する。 これは実装にとって十分すぎるはずである。
グローバル プライバシー予算ストアは、キーが エポックインデックスであり、値が 32 ビット符号なし整数であるマップであり、 microepsilon単位である。
グローバルプライバシー予算ストアは、 すべてのサイトにまたがって適用され、 各エポックで更新される単一の プライバシー予算の消費を追跡する。 これは、同じ人物の活動を複数のサイトにまたがって相関させることができる 敵対者に対する安全制限を提供する。
サイトごとのプライバシー予算ストアとは異なり、 グローバルプライバシー予算ストアは エポックインデックスのみによってキー付けされ、 サイトによってはキー付けされない。
インプレッション サイトクォータストアは、キーが プライバシー予算キーであり、 値が32 ビット符号なし整数であるマップであり、 microepsilon単位である。
インプレッションサイトクォータストアは、 単一のインプレッション サイトが一つのエポックで寄与できる「在庫」 (インプレッションに関連するプライバシー予算)の量を制限する。 これは、単一のインプレッションサイトが、 悪意をもって引き起こされ得るグローバル制限から過剰な量を消費することを防ぐ。
-
isSingleEpoch の場合は l1Norm、そうでない場合は 2 * value を l1NormSensitivity とする。
-
2 * value を valueSensitivity とする。
-
2 * maxValue / epsilon を noiseScale とする。
-
l1NormSensitivity / noiseScale を l1NormDeductionFp とする。
-
valueSensitivity / noiseScale を valueDeductionFp とする。
単一エポックの attribution は、 エポックをまたぐ連鎖的影響を生じさせない。 複数エポックに関与する Attribution は、 1 つの変更がエポックをまたいで attribution に影響する可能性があるため、 2 倍の予算を消費する。 控除を 2 倍にすることは、 maxValue / epsilon に比例するラプラスノイズが 集計ヒストグラムに追加されることを前提としている。
-
l1NormDeductionFp * 1000000 を正の無限大方向に丸めたものを l1NormDeduction とする。
-
valueDeductionFp * 1000000 を正の無限大方向に丸めたものを valueDeduction とする。
-
attribution budget lock が true の場合、 その値が false になるまで待機し、 その後その値を true に設定する。
-
key、l1NormDeduction、valueDeduction、 impressions、および isSingleEpochを指定して 利用可能なプライバシー予算を確認するを 呼び出した結果が false の場合、次の手順を実行する。
-
attribution budget lock を false に設定する。
-
false を返す。
-
-
すべての予算確認に合格したので、控除を実行する。
-
isSingleEpoch の場合は l1NormDeduction を deduction とし、そうでない場合は valueDeduction を deduction とする。
-
プライバシー予算ストア内で key の値を取得する結果を、 サイトごとのプライバシー予算をデフォルトとして、 currentValue とする。
-
プライバシー予算ストア内の key の値を currentValue − deduction に設定する。
-
key のエポックインデックス要素を epoch とする。
-
deductedGlobalBudgets が epoch を含まない場合、 deductedGlobalBudgets に epoch を追加し、 グローバルプライバシー予算 ストア[epoch] を valueDeduction だけ減算する。
-
impressions 内の各 impression について反復する。
-
impression のimpression siteを impressionSite とする。
-
epoch および impressionSite を項目とする プライバシー予算 キーを impressionQuotaKey とする。
以下は、そのサイトに対して複数のインプレッションがある場合に、 同じインプレッションサイトクォータから複数回予算を控除しないことを保証する。
-
deductedImpressionQuotas が impressionQuotaKey を含まない場合:
-
deductedImpressionQuotas に impressionQuotaKeyを追加する。
-
エポックごとのインプレッションサイトクォータを デフォルトとして、 エポックごとのインプレッションサイトクォータ内の impressionQuotaKey の値を取得する結果を currentImpressionQuotaValue とする。
-
エポックごとのインプレッションサイトクォータ[impressionQuotaKey\] の値を currentImpressionQuotaValue − valueDeduction に設定する。
-
-
-
-
attribution budget lock を false に設定する。
-
true を返す。
-
isSingleEpoch の場合は l1NormDeduction を deduction とし、そうでない場合は valueDeduction を deduction とする。
-
プライバシー予算ストアから key の値を取得する値を、 サイトごとのプライバシー予算をデフォルトとして、 currentValue に設定する。
-
deduction が currentValue より大きい場合、false を返す。
-
key のエポックインデックス要素を epoch とする。
-
グローバルプライバシー予算ストアから epoch の値を取得する値を、 エポックごとのグローバルプライバシー予算をデフォルトとして、 currentGlobalValue に設定する。
-
valueDeduction が currentGlobalValue より大きい場合、false を返す。
-
impressions 内の各 impression について反復する。
-
impression のimpression siteを impressionSite とする。
-
epoch および impressionSite を項目とする プライバシー予算キーを impressionQuotaKey とする。
-
インプレッションサイトクォータストアから impressionQuotaKey の値を取得する値を、 エポックごとのインプレッションサイトクォータを デフォルトとして currentImpressionQuotaValue に設定する。
-
valueDeduction が currentImpressionQuotaValue より大きい場合、 false を返す。
-
-
true を返す。
4.2.2. Attribution API の有効化
The Attribution API は、一時的アクティベーション消費 APIを おおよそのモデルとしている。 そこでは、ユーザーアクティベーションが 一時的に API を利用可能にする。 いくつかの違いにより、この設計は 一時的アクティベーション消費 APIと区別される:
-
任意のユーザーアクティベーションは、 Attribution API を短い期間利用可能にする。
-
さらに、ナビゲーションがユーザーにより開始される場合 (すなわち、ユーザーナビゲーション関与が "browser UI" である場合)、 Attribution API は短い期間利用可能になる。
-
最後のアクティベーションから実装定義の期間内に saveImpression() または measureConversion() のいずれかを呼び出して API へアクセスする最初の試みは、 その site に対して API を有効にする。
-
各アクティベーションは、最大 1 つの site に対して API を利用可能にする。 一時的アクティベーションにおいて アクティベーションを消費すると、 別のアクティベーションが発生するまで他の同様の API が利用できなくなるのと同様に、 ある site で API を使用すると、他の site では API が利用できなくなる。
-
API が正常に使用されると、 API は、次のクロスサイトナビゲーションまで、 トップレベル traversable のアクティブ文書の すべての子孫 navigable (すなわち、現在のページ上のすべてのフレーム)での使用に対して有効になる。
-
ナビゲーションにより、トップレベル traversableが 別のsiteへ移動すると、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 つの状態を追跡する:
-
attribution enabled flag は、API が有効であるかどうかを追跡する boolean 値である。 この値は false に初期化される。
-
attribution activation timestamp は、 最後のユーザーアクティベーションを追跡する momentである。 この値はunix epochに初期化される。
実装は、attribution activation duration も、 実装定義のdurationとして設定する。 これは一時的アクティベーション期間以上であるべきだが、 ナビゲーションによる遅延が Attribution API をアクセス不能にしないことを保証するため、 より大きな値が望ましい場合がある。
実装は、ページ読み込み時間に伴う遅延を考慮するため、 許容される時間を延長することを選んでもよい。 固定値では、デバイスや使用されるネットワークにおける性能差を 考慮できない可能性がある。 実装は、性能特性の理解に基づいて、 attribution activation duration の値を 延長してもよい。 あるいは、実装はページ読み込み中に任意のタイマーを一時停止してもよい。
Document
document 内でアクティベーションを引き起こす入力イベントが発火する場合、
ユーザーエージェントは、イベントを配送する前に、
アクティベーション通知手順に加えて、以下の手順を
実行しなければならない。
この場合、navigable navigable を null に設定する。
あるいは、ナビゲーションが開始するとき、
ユーザーナビゲーション関与が
"browser UI" である場合、
navigable を影響を受けるnavigableに設定し、
document を null に設定して、
以下の手順を実行する。
手順は次のとおりである:
-
navigable が null でない場合、n を navigable とする。
-
そうでなければ、n を、document のノード navigableを取得した結果とする。
-
top を、n のトップレベル traversableを取得した結果とする。
-
top のattribution activation timestampを 現在の高解像度時刻に設定する。
-
documentState のinitiator originが responseOrigin とsame siteである場合、返す。
-
top のattribution enabled flagを false に設定する。
Document
document が与えられ、
失敗時に "NotAllowedError"
DOMException
を投げるものとして、
attribution
API activation を確認するには:
-
n を、document のノード navigableを取得した結果とする。
-
top を、n のトップレベル traversableを取得した結果とする。
-
top のattribution enabled flagが true である場合、返す。
-
lastActivation を top のattribution activation timestampとする。
-
lastActivation にattribution activation duration を加えたものが、現在の高解像度時刻より小さい場合、
"NotAllowedError"DOMExceptionを投げる。 -
top のattribution enabled flagを true に設定する。
4.2.3. エポック開始時刻
プライバシーバジェットエポック(またはエポック)は、 ある期間を識別する。 エポックの長さは、1 週間、すなわち 7 日に固定される。 ここで、日は 86400 秒として定義される。
エポック開始時刻は、 壁時計からの時点である。 エポックは、 各ユーザーエージェントについて、 週の中からランダムに選択された時刻に開始する。 これにより、プライバシー バジェットがゼロに達することで生じる集計の偏りが、 すべてのユーザーからのすべての貢献全体に 平均化されることが保証される。
開始時刻は、 現在の エポックを取得するアルゴリズムを呼び出した副作用として、エポックが最初に必要になったときに ユーザーエージェントによってランダムに選択される。
エポックインデックスは、 与えられたエポックを参照する整数である。 エポックインデックスは、 インプレッション およびエポック開始時刻に アクセスするために使用される。
エポックインデックスは、 設定された参照点に相対的な 整数として保存される。 この仕様におけるエポックインデックスは、 エポック開始 時刻 を参照点として使用する。 ユーザーエージェントは、別の時点を使用して、 “ゼロ”または参照エポックを示すことを選択してもよい。
この仕様のアルゴリズムはすべて、より抽象的なエポックではなく、 具体的なエポックインデックスを使用する。 時点は、 現在の エポックを取得するアルゴリズムを使用して、 対応するエポックのエポックインデックスへ変換される。
-
start をエポック開始時刻とする。
-
elapsed を (t − start) / period とする。
-
elapsed を、負の無限大方向に丸めた整数として返す。
4.2.4. 最後の閲覧履歴消去時刻
直近の閲覧履歴消去は、 閲覧履歴が最後に消去された時刻を追跡する、 壁時計を使用する時点である。 直近の閲覧履歴消去値は、 ユーザーの要求により いずれかのサイトレベル状態が消去されたときに、 現在の粗化された壁時計時刻 に更新される。 この値は最初は未設定である。
任意の最適化として、 次のすべてが true である場合、直近の閲覧履歴消去の更新を省略できる:
-
消去されるすべてのインタラクションが、 消去されていない他のインタラクションを持つサイト とのものである。
-
消去されるすべてのインタラクションが、 同じサイトとの他のインタラクションが保持された エポック中に発生したものである。
-
エポック開始 時刻が設定されている。
3 つの条件がすべて true である場合、 直近の閲覧履歴消去は更新する必要がない。 代わりに、影響を受けるすべてのサイトおよびエポック (対応するエポックインデックスを使用する) から形成できるすべてのプライバシーバジェット キーの組み合わせについて、 値 0 を設定することで、 プライバシー バジェットストアを更新しなければならない。
この最適化は、ユーザーエージェントが、 影響を受けるサイトとのインタラクションに関する情報を、 影響を受けるエポック内で保持していることに依存する。 これは、保持されているインタラクションのいずれもが バジェットの枯渇をもたらした可能性があるためにのみ機能する。 閲覧履歴の空白に関する情報が 露出しないようにするには、バジェットをリセットする必要がある。
-
earliestEpochIndex を、 now − 最大 lookback 日数で現在のエポックを取得する 結果とする。
これにより、可能なすべてのインプレッションを照会できることが保証される。
-
startEpoch を earliestEpochIndex とする。
-
直近の閲覧履歴消去が設定されている場合、 次の手順を実行する:
-
clearEpoch を、直近の閲覧履歴消去の値で 現在の エポックを取得する 結果とする。
この現在のエポックを取得する の使用は、負の値を返すことがある。 これは、エポック開始時刻 が、履歴が最後に消去された後の時刻に設定される可能性が高いためである。
-
clearEpoch を clearEpoch + 1 に設定する。
1 を加えることは、attribution 用のエポック範囲が、 閲覧履歴が消去される前のエポック と重ならないようにするために必要である。
-
clearEpoch が startEpoch より大きい場合、 clearEpoch を返す。
-
-
startEpoch を返す。
-
forgetVisits が false の場合:
-
sites 内の各 site について反復する:
-
startingEpoch を、 now が与えられてattribution 用の開始エポックを 取得するを呼び出した結果とする。
-
currentEpoch を、 now が与えられて現在のエポックを取得する を呼び出した結果とする。
-
startingEpoch から currentEpoch までの包括範囲 内の各 epoch について反復する:
-
key を、site と epoch から形成される プライバシー バジェットキーとする。
-
プライバシー バジェットストア[key] を 0 に設定する。
-
-
-
返る。
-
sites が空である場合:
-
sites が空でない場合:
-
インプレッションストア内の各 impression について反復し、 sites が impression のインプレッションサイトを含む場合、 impression をインプレッションストアから削除する。
-
プライバシーバジェットストアのキー 内の各 key について反復し、 sites が key のサイト構成要素を含む場合、 プライバシーバジェット ストア[key] を削除する。
-
インプレッションサイトクォータストアのキー 内の各 key について反復し、 sites が key のサイト構成要素を含む場合、 インプレッションサイトクォータ ストア[key] を削除する。
この処理はグローバル プライバシーバジェットストアには触れない。 主として、これはプライバシーバジェットが、 いったん消費されたら忘れられないことを保証するためである。
-
-
直近の閲覧履歴消去を now に設定する。
一部のサイトについてのみ状態を消去している間 (すなわち、sites が空で ない場合)に 直近の閲覧履歴消去を設定すると、 その集合に含まれていないサイトについて、一部のインプレッションに到達できなくなる。 実装は、その結果として使用できなくなる 使用不能なインプレッションや バジェット記録 (グローバルプライバシーバジェットストア内のものなど) も削除できる。
4.3. インプレッション保存アルゴリズム
saveImpression(options) メソッド手順は
次のとおりである。
-
this から 暗黙の API 入力を取得する結果を implicitInputs とする。
-
Assert: implicitInputs は null でない。
-
options および implicitInputs を指定して インプレッションを保存するを実行した結果を返す。
AttributionImpressionOptions
options
および暗黙的 API
入力 implicitInputs が与えられ、
インプレッションを
保存するには:
-
document を implicitInputs の関連付けられた文書とする。
-
realm を document の関連するレルムとする。
-
document が "
save-impression" という名前のポリシー制御機能を使用することを許可されていない場合、 realm 内の"NotAllowedError"DOMExceptionで却下された promiseを返す。 -
document が与えられて、 attribution API activation を確認する。 投げられた理由があれば、その理由で却下された promiseを返す。
-
ページから供給される API 入力を検証する:
-
options.
histogramIndexが 実装定義の最大ヒストグラムサイズ以上である場合、 realm 内のRangeErrorで却下された promiseを返す。 -
options.
lifetimeDaysが 0 である場合、 realm 内のRangeErrorで却下された promiseを返す。 -
options.
lifetimeDaysを最大 lookbackに丸め込む。 -
options.
conversionSitesのサイズが、 実装定義の インプレッションあたりの 最大 conversion site 数より大きい場合、 realm 内のRangeErrorで却下された promiseを返す。 -
conversionSites を、options.
conversionSites内の各値について サイトを解析する を呼び出した結果である集合とする。 -
conversionSites 内のいずれかの結果が failure である場合、 realm 内の
"SyntaxError"DOMExceptionで却下された promiseを返す。 -
options.
conversionCallersのサイズが、 実装定義の インプレッションあたりの 最大 conversion caller 数より大きい場合、 realm 内のRangeErrorで却下された promiseを返す。 -
conversionCallers を、options.
conversionCallers内の各値について サイトを解析する を呼び出した結果である集合とする。 -
conversionCallers 内のいずれかの結果が failure である場合、 realm 内の
"SyntaxError"DOMExceptionで却下された promiseを返す。
-
-
次の手順を並列に実行する:
-
impression を、次から構成される保存済みインプレッションとして構築する:
- Match Value
-
options.
matchValue - Impression Site
-
implicitInputs のトップレベルサイト
- Intermediary Site
-
implicitInputs の中間サイト
- Conversion Sites
-
conversionSites
- Conversion Callers
-
conversionCallers
- Timestamp
-
implicitInputs のtimestamp
- Lifetime
-
options.
lifetimeDays日 - Histogram Index
-
options.
histogramIndex - Priority
-
options.
priority
-
Attribution API が有効である場合、 impression をインプレッションストアに保存する。
-
-
result を新しい
AttributionImpressionResultとする。 -
realm 内の result で解決された promiseを返す。
saveImpression() は、インプレッションが記録されたかどうかを示すステータスを返さない。 これにより、Attribution API が無効であるときを検出する能力が最小化される。
実装は、API 状態を明らかにしうるサイドチャネル を軽減することを試みなければならない。例えば、返される promise の解決は、 impression をインプレッションストアに保存することを前提にしない。 これは、解決にかかる時間が、既存の インプレッション数や API が有効かどうかに依存しないことを保証するためである。
暗黙的 API 入力は、次のフィールドを持つ構造体である:
-
window を realm のグローバルオブジェクトとする。
-
window が
Windowでない場合、null を返す。 -
settings を realm の設定オブジェクトとする。
-
timestamp を settings の現在の壁時計時刻とする。
-
topLevelOrigin を settings のトップレベルオリジンとする。
-
origin が null の場合、origin を settings のオリジンに設定する。
-
topLevelSite を、topLevelOrigin からサイトを取得する結果とする。
-
intermediarySite を次の値とする:
-
次のフィールドを持つ暗黙的 API 入力を返す:
4.4. コンバージョン測定アルゴリズム
measureConversion() メソッドは 非同期に完了し、Attribution タスクソース上に作業をキューする。
measureConversion(options) メソッド
手順は次のとおりである:
-
implicitInputs を、this から暗黙的 API 入力を取得する結果とする。
-
表明する:implicitInputs は null でない。
-
options および implicitInputs でconversion を測定するを実行した結果を返す。
AttributionConversionOptions
options
および暗黙的 API
入力 implicitInputs が与えられ、
conversion を
測定するには:
-
document を implicitInputs の関連付けられた文書とする。
-
realm を document の関連するレルムとする。
-
document が "
measure-conversion" という名前のポリシー制御機能を使用することを許可されていない場合、 realm 内の"NotAllowedError"DOMExceptionで却下された promiseを返す。 -
帰属 API の有効化をチェック が document を受け取り、投げられた任意の理由で拒否されたプロミスを返す。
-
validatedOptions を、 options を検証する結果とする。 投げられた理由があれば、その理由で却下された promiseを返す。
-
promise を realm 内の新しい promiseとする。
-
次の手順を並列に実行する:
-
report を、validatedOptions のヒストグラムサイズで 全ゼロヒストグラムを作成するを呼び出した結果とする。
-
Attribution API が有効である場合、 report を、validatedOptions、 implicitInputs のトップレベルサイト、 implicitInputs の中間サイト、および implicitInputs のtimestamp でattribution を行いヒストグラムを埋める結果に設定する。
-
aggregationService を validatedOptions のaggregation serviceとする。
-
aggregationService.
protocolの値で分岐する:dap-18-histogram-
次の手順を実行する:
-
encryptedReport を、validatedOptions、 implicitInputs のトップレベル site、 implicitInputs の仲介 site、 implicitInputs のtimestamp、および report が与えられたうえで、 DAP レポートを構築するを呼び出した結果とする。
-
-
result を、次の項目を持つ
AttributionConversionResultとする:report-
encryptedReport
-
promise を result で解決するため、 タスクをキューする。 これはAttribution タスクソース上で行う。
-
-
promise を返す。
実装は、API 状態を明らかにしうるサイドチャネル を軽減することを試みなければならない。例えば、理想的には、返される promise の解決にかかる時間は、 保存または一致したインプレッション数や API が有効かどうかに依存しないことになる。
検証済み conversion optionsは、次のフィールドを持つ構造体である:
| Aggregation Service: | AttributionAggregationService
のインスタンス。
|
|---|---|
| Epsilon: | 有限の正の数。 |
| Histogram Size: | 32 ビット符号なし整数。 |
| Lookback: | 正の期間。 |
| Match Values: | 32 ビット符号なし整数の集合。 |
| Impression Sites: | サイトの集合。 |
| Impression Callers: | サイトの集合。 |
| Credit: | 数値のリスト。 |
| Value: | 32 ビット符号なし整数。 |
| Max Value: | 32 ビット符号なし整数。 |
AttributionConversionOptions
を検証するには:
-
aggregationServices が、 options.
aggregationServiceのキーを持つ entryを含まない場合、ReferenceErrorを投げる。 -
aggregationService を、 options.
aggregationServiceが与えられて、AttributionAggregationServicesから値を取得する結果とする。 -
options.
epsilonが 0 以下、またはmaximum epsilonより大きい場合、RangeErrorを投げる。 -
options.
histogramSizeが 0、または実装定義の最大ヒストグラム サイズより大きい場合、 または options.aggregationServiceについて、存在するならmaximum aggregation-service histogram sizeより大きい場合、RangeErrorを投げる。 -
options.
valueが 0 である場合、RangeErrorを投げる。 -
options.
valueが options.maxValueより大きい場合、RangeErrorを投げる。 -
credit が空である場合、
RangeErrorを投げる。 -
credit の項目のいずれかが 0 以下である場合、
RangeErrorを投げる。 -
credit のサイズが、実装定義の maximum number of credit valuesを超える場合、
RangeErrorを投げる。 -
lookback を、options.
lookbackDaysが存在する場合はその値とし、 そうでない場合は最大 lookback 日とする。 -
lookback がその最大値より大きい場合、 lookback を最大 lookback 日に設定する。
-
lookback が 0 日である場合、
RangeErrorを投げる。 -
options.
matchValuesのサイズが、 実装定義のmaximum number of match valuesより大きい場合、RangeErrorを投げる。 -
matchValues を、 options.
matchValuesで集合を作成するを実行した結果とする。 -
options.
impressionSitesのサイズが、 実装定義のconversion 用の最大 impression site 数より大きい場合、RangeErrorを投げる。 -
impressionSites を、options.
impressionSites内の各値についてサイトを 解析するを呼び出した結果である集合とする。 -
impressionSites 内のいずれかの結果が failure である場合、
"SyntaxError"DOMExceptionを投げる。 -
options.
impressionCallersのサイズが、 実装定義のconversion 用の 最大 impression caller 数より大きい場合、RangeErrorを投げる。 -
impressionCallers を、options.
impressionCallers内の各値についてサイトを 解析するを呼び出した結果である集合とする。 -
impressionCallers 内のいずれかの結果が failure である場合、
"SyntaxError"DOMExceptionを投げる。 -
次のフィールドを持つ検証済み conversion optionsを返す:
- Aggregation Service
-
aggregationService
- Epsilon
-
options.
epsilon - Histogram Size
-
options.
histogramSize - Lookback
-
lookback
- Match Values
-
matchValues
- Impression Sites
-
impressionSites
- Impression Callers
-
impressionCallers
- Credit
-
credit
- Value
-
options.
value - Max Value
-
options.
maxValue
4.4.1. Attribution ロジック
Attribution ロジックは、 コンバージョン値をヒストグラムバケットにどのように割り当てるかを決定する。
undefined intermediarySite、および
時点
now が与えられた場合:
-
now を指定して現在のエポックを取得する結果を currentEpoch とする。
-
now を指定してattribution の開始エポックを 取得する結果を startEpoch とする。
-
(now − options のルックバック) を渡して、 現在のエポックを取得するを 呼び出した結果を earliestEpoch とする。
-
currentEpoch が earliestEpoch と等しい場合は true、 そうでなければ false を isSingleEpoch とする。
-
l1Norm を 0 とする。
-
isSingleEpoch が true の場合:
-
options、topLevelSite、intermediarySite、 currentEpoch、および nowを指定して共通照合 ロジックを呼び出した結果を impressions とする。
-
impressions が空で ある場合、options のヒストグラムサイズを指定して 全ゼロヒストグラムを作成するを 呼び出した結果を返す。
-
impressions、 options のヒストグラムサイズ、 options の値、および options のcreditを指定して last-n-touch attribution で ヒストグラムを埋めるを実行した結果を histogram とする。
-
histogram 内の項目の合計を l1Norm とする。
-
-
新しい集合を deductedImpressionQuotas とする。
-
新しい集合を deductedGlobalBudgets とする。
-
startEpoch から currentEpoch までの各 epoch について、両端を含めて:
-
options、topLevelSite、intermediarySite、 epoch、および nowを指定して共通照合 ロジックを呼び出した結果を impressions とする。
単一エポックの場合、これは matchedImpressionsを再計算している。 実装は、その作業を二度行わないようにしたいだろう。
-
impressions が空で ない場合:
-
epoch および topLevelSiteを項目とする プライバシー予算キーを key とする。
-
key、impressions、 options のepsilon、 options の値、 options の最大値、 isSingleEpoch、l1Norm、 deductedImpressionQuotas、および deductedGlobalBudgetsを指定して プライバシーおよび安全予算を 控除するを呼び出した結果を budgetAndSafetyOk とする。
-
budgetAndSafetyOk が true の場合、 matchedImpressions を impressions で拡張する。
-
-
-
matchedImpressions が空で ある場合、 options のヒストグラムサイズを指定して 全ゼロヒストグラムを作成するを 呼び出した結果を返す。
-
matchedImpressions、 options のヒストグラムサイズ、 options の値、および options のcreditを指定して last-n-touch attribution で ヒストグラムを埋めるを実行した結果を histogram とする。
-
histogram を返す。
4.4.2. 共通インプレッション照合ロジック
undefined intermediarySite、
エポックインデックス epoch、および
時点
now が与えられた場合:
-
インプレッションストア内の 各 impression について反復する。
-
impression のタイムスタンプを渡して、 現在の エポックを取得するを呼び出した結果を impressionEpoch とする。
-
impressionEpoch が epoch と等しくない場合、 continueする。
-
now が、impression のタイムスタンプに impression の有効期間を加えた時刻より後である場合、 continueする。
-
now が、impression のタイムスタンプに options のルックバックを加えた時刻より後である場合、 continueする。
-
impression のコンバージョンサイトが空でなく、 かつ topLevelSite を含まない場合、 continueする。
-
intermediarySite が
undefinedでない場合は intermediarySite を、そうでなければ topLevelSite を conversionCaller とする。 -
impression のコンバージョン呼び出し元が空でなく、 かつ conversionCaller を含まない場合、 continueする。
-
options のmatch valueが空でなく、 かつ impression のmatch valueを含まない場合、 continueする。
-
options のインプレッションサイトが 空でなく、かつ impression のインプレッションサイトを含まない場合、 continueする。
-
impression の仲介サイトが
undefinedでない場合はそれを、 そうでなければ impression のインプレッションサイトを impressionCaller とする。 -
options のインプレッション呼び出し元が 空でなく、 かつ impressionCaller を含まない場合、 continueする。
-
impression を matching に追加する。
-
-
matching を返す。
4.4.2.1. Last-N-Touch Attribution
-
credit の項目の合計を sumCredit とする。
-
新しいリストを roundedCredit とする。
-
credit の各 item について反復する。
-
value * item / sumCredit を normalizedCredit とする。
-
normalizedCredit を roundedCredit に追加する。
-
-
idx1 を 0 とする。
-
roundedCredit のインデックスを取得するから、最初の項目を除いた各 n について反復する。
-
idx2 を n とする。
-
roundedCredit[idx1] − floor(roundedCredit[idx1]) を frac1 とする。
-
roundedCredit[idx2] − floor(roundedCredit[idx2]) を frac2 とする。
-
frac1 と frac2 の両方がゼロに等しい場合、 continueする。
-
frac1 + frac2 が 1 より大きい場合、 incr1 を 1 − frac1 とし、 incr2 を 1 − frac2 とする。
-
そうでなければ、incr1 を −frac1 とし、 incr2 を −frac2 とする。
incr1 は、 roundedCredit[idx1] が整数になるよう増分する量を表し、 incr2 および idx2 についても同様である。 これらの値は負になり得ることに注意。
-
incr2 / (incr1 + incr2) を p1 とする。
p1 の値は、idx1 内の項目が整数へ丸められる確率を表す。 incr1 + incr2 が 0 のときにゼロ除算が発生するが、 これは frac1 と frac2 の両方が整数である場合 (両方が 0、または正確に 1 のいずれか)にのみ可能である。 この場合、idx2 を丸める必要はないため、単にスキップする。
-
0 から 1(含む)の間のランダムな double を r とする。
-
r が p1 より小さい場合、 incr を incr1 とし、 idx1 と idx2 の値を交換する。
-
そうでなければ、incr を incr2 とする。
-
roundedCredit[idx2] を incr だけ増分する。
-
roundedCredit[idx1] を incr だけ減分する。
-
-
roundedCredit から項目をすべて 最も近い整数へ丸めることで整数に変換し、 ちょうど中間の場合はゼロから離れる方向に丸めた結果を integerCredit とする。
-
integerCredit を返す。
この最後の丸め手順は、微小な浮動小数点の 加算および減算誤差によって、 roundedCredit[idx1] の小数部分が完全には取り除かれない場合のためだけにある。 半分のときの丸めモードが実際に発生することはなく、実装を容易にするため C++ の
std::roundの挙動と一致するよう選択されている。このアルゴリズムの目的は、 1) 割り当て全体にわたって正確に value の総値を割り当てること、 2) integerCredit の期待値が正規化された credit (すなわち、credit * value / sumCredit。 ここで * は要素ごとの乗算を表す)と正確に等しいという性質を維持すること、 3) どの割り当てにも 1 を超える誤差を生じさせないことである。
-
matchedImpressions を、優先度、次にタイムスタンプで 降順にソートしたものを sortedImpressions とする。
-
sortedImpressions の先頭 N 個のエントリーを lastNImpressions とする。
-
credit の先頭 N 個を除くすべてのエントリーを削除する。
-
credit および valueを指定してcredit を公平に 割り当てる結果を normalizedCredit とする。
-
histogramSize を指定して全ゼロ ヒストグラムを作成するを呼び出した結果を histogram とする。
-
lastNImpressions のインデックスの各 i について反復する。
-
lastNImpressions[i] を impression とする。
-
normalizedCredit[i] を value とする。
-
impression のヒストグラムインデックスを index とする。
-
index が histogram のサイズより小さい場合、 histogram[index] を value だけ増分する。
-
-
histogram を返す。
4.5. 実装定義値の設定
この仕様はいくつかの実装定義値を識別する。 この節では、実装がそれらの値を最適に設定する方法についての いくつかの推奨事項を含む。
実装は、lifetimeDays
および
lookbackDays
について、実装定義の 最大 lookback
を設定する。
最大 lookbackは、
正の整数個の日である。
これらの値について異なる最大値を持たせても意味はない。
2 つのうち小さい方の値が、
どの保存済みインプレッションが conversion
に利用できるかを決定するためである。
実装は、少なくとも 30 日の最大 lookbackを設定しなければならない。 この期間内に、実装はインプレッションサイトごとに少なくとも 1000 個のインプレッションを保持するよう 試みるべきである。
実装は、可能な場合、 時間および個数に関するこれらの推奨される制限を超えてインプレッションを保持するべきである。 インプレッションを保存するために利用可能な容量は、 インプレッションデータを保持するために必要なストレージと、 conversion report を生成するために必要な処理時間の両方に依存する。 実装は、サイトが利用可能な容量を超えてインプレッションの保存を要求した場合、 ユーザーに要求された場合(§ 10.2 Attribution API の無効化を参照)、 または実装定義の理由により、 これらの制限に達する前にインプレッションを破棄してもよい。
実装がインプレッションを保持しないことを選択しうる理由の 1 つは、 そのサイトが十分なユーザーエンゲージメントを受けていないことである。
saveImpression()
および measureConversion()
に渡されるサイトのリストについて、実装定義値が選択される。
インプレッションあたりの最大 conversion site 数
は、conversionSites
の値の個数に対する制限であり、
実装はこの値を少なくとも 5 に設定しなければならない。
インプレッションあたりの最大 conversion caller 数
および conversion 用の最大 impression caller 数
は、それぞれ conversionCallers
および impressionCallers
の値の個数に対する制限であり、
実装はこれらの値をそれぞれ少なくとも 10 に設定しなければならない。
conversion 用の最大 impression site 数
は、impressionSites
の値の個数に対する制限であり、
実装はこの値を少なくとも 30 に設定しなければならない。
credit
の値の個数に対する制限である
最大
credit 値数について、実装定義値が選択される。
実装はこの値を少なくとも 10 に設定しなければならない。
matchValues
の値の個数に対する制限である
最大
match value 数について、実装定義値が選択される。
実装はこの値を少なくとも 30 に設定しなければならない。
measureConversion() によって生成されるヒストグラムのサイズは、 実装定義の 最大ヒストグラムサイズ と maximum aggregation-service histogram size の両方の対象となる。 最大ヒストグラムサイズには最小値は設定されない。 集計技術の選択によって制限が設定されることが期待されるためである。 maximum aggregation-service histogram size は、aggregation serviceで使用される技術の選択によって決定される 固定値となる。 これは実装定義ではない。
4.5.1. プライバシーおよび安全制限パラメーター構成
ユーザー エージェントは、次について値を定義することで、 プライバシーバジェットおよび安全上の制限を構成する:
-
サイトごとの プライバシーバジェット(εsite)は実装定義である。 差分プライバシー集計を用いた実験では、 1(よりプライベート)から 10(より高性能)の範囲の値で 妥当な性能を達成できることが示されている。
-
エポックごとのグローバルプライバシーバジェット(εglobal) は、 サイト全体で エポックごとに利用可能な 最大プライバシーバジェットであり、 マイクロイプシロンで指定される。 実装は、この値をべきである、 サイトごとのプライバシーバジェットの、エポックごとの倍数として設定する。
-
エポックごとのインプレッションサイトクォータ (εimp-quota)は、 単一のインプレッションサイトが エポックごとに グローバルプライバシーバジェットから消費可能にできる 最大プライバシーバジェットであり、 マイクロイプシロンで指定される。 実装は、この値をべきである、 サイトごとのプライバシーバジェットの、エポックごとの倍数として設定する。
安全上の制限をサイトごとのバジェットの倍数として構成することで、 複数のサイトによって API をどのように使用できるかが決まる。 この倍数を設定する際に、 実装は、バジェットを使用する可能性のあるサイト数として どの程度を想定するかを考慮する必要があり、 バジェットを完全には使用しないサイトを考慮して 下方修正することもある。
安全上の制限をサイトごとのバジェットの倍数として設定することで、 共有制限を使い尽くすには多くのサイトによる協調が必要になることが保証され、 それらは主たるプライバシー機構としてではなく、 濫用から保護する手段として主に有用になる。
5. HTTP API
5.1. インプレッションの保存
`Save-Impression` は、
Dictionary Structured Headerであり、
ユーザーエージェントに
saveImpression() API を呼び出すよう要求する応答に設定される。
saveImpression
例に相当する HTTP である:
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 の値。 正の整数である。このキーは任意である。
Save-Impression ヘッダーを解析するには、次の手順を実行する。
-
input_bytes を input に設定し、 field_type を "
dictionary" に設定して structured fields を 解析する結果を dict とする。 -
解析が失敗した場合、エラーを返す。
-
dict["
histogram-index"] を、undefinedをデフォルトとして取得したものを histogramIndex とする。 -
histogramIndex が32 ビット符号なし整数範囲内の整数でない場合、 エラーを返す。
-
次の項目を持つ新しい
AttributionImpressionOptionsを opts とする。histogramIndex-
histogramIndex
-
dict["
conversion-sites"] が存在する場合:-
その値を conversionSites とする。
-
conversionSites が内部 リストでない場合、または conversionSites の項目のいずれかが 文字列でない場合、 エラーを返す。
-
opts.
conversionSitesを conversionSites に設定する。
-
-
dict["
conversion-callers"] が存在する場合:-
その値を conversionCallers とする。
-
conversionCallers が内部 リストでない場合、または conversionCallers の項目のいずれかが 文字列でない場合、 エラーを返す。
-
opts.
conversionCallersを conversionCallers に設定する。
-
-
dict["
match-value"] が存在する場合:-
その値を matchValue とする。
-
matchValue が 32 ビット符号なし整数範囲内の 整数でない場合、 エラーを返す。
-
opts.
matchValueを matchValue に設定する。
-
-
dict["
lifetime-days"] が存在する場合:-
その値を lifetimeDays とする。
-
lifetimeDays が正の整数でない場合、 エラーを返す。
-
opts.
lifetimeDaysを lifetimeDays に設定する。
-
-
-
その値を priority とする。
-
priority が 32 ビット符号付き整数範囲内の 整数でない場合、 エラーを返す。
-
opts.
priorityを priority に設定する。
-
-
opts を返す。
5.2. コンバージョンの測定
`Measure-Conversion` は、
Dictionary Structured Headerであり、
ユーザーエージェントに
measureConversion() API を呼び出すよう要求する応答に設定される。
measureConversion 例に相当する HTTP であり、
生成されたレポートが POST される report-url が追加されている:
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 に対して相対でもよい。そのスキームは "https" でなければならない。 このキーは必須である。
Measure-Conversion ヘッダーを解析するには、次の手順を実行する。
-
input_bytes を input に設定し、 field_type を "
dictionary" に設定して structured fields を 解析する結果を dict とする。 -
解析が失敗した場合、エラーを返す。
-
dict["
aggregation-service"] を、undefinedをデフォルトとして取得したものを aggregationService とする。 -
aggregationService が文字列でない場合、 エラーを返す。
-
dict["
histogram-size"] を、undefinedをデフォルトとして取得したものを histogramSize とする。 -
histogramSize が32 ビット符号なし整数範囲内の正の整数でない場合、 エラーを返す。
-
dict["
report-url"] を、undefinedをデフォルトとして取得したものを reportUrlString とする。 -
reportUrlString が文字列でない場合、 エラーを返す。
-
baseUrl を伴って reportUrlString にURL パーサーを適用した結果を reportUrl とする。
-
reportUrl が失敗の場合、エラーを返す。
-
reportUrl が潜在的に信頼できる URLでない場合、エラーを返す。
-
reportUrl のスキームが "
https" でない場合、エラーを返す。 -
次の項目を持つ新しい
AttributionConversionOptionsを opts とする。aggregationService-
aggregationService
histogramSize-
histogramSize
-
dict["
lookback-days"] が存在する場合:-
その値を lookbackDays とする。
-
lookbackDays が正の整数でない場合、 エラーを返す。
-
opts.
lookbackDaysを lookbackDays に設定する。
-
-
dict["
match-values"] が存在する場合:-
その値を matchValues とする。
-
matchValues が内部 リストでない場合、または matchValues の項目のいずれかが 32 ビット符号なし整数範囲内の整数でない場合、エラーを返す。
-
opts.
matchValuesを matchValues に設定する。
-
-
dict["
impression-sites"] が存在する場合:-
その値を impressionSites とする。
-
impressionSites が内部 リストでない場合、または impressionSites の項目のいずれかが 文字列でない場合、 エラーを返す。
-
opts.
impressionSitesを impressionSites に設定する。
-
-
dict["
impression-callers"] が存在する場合:-
その値を impressionCallers とする。
-
impressionCallers が内部 リストでない場合、または impressionCallers の項目のいずれかが 文字列でない場合、 エラーを返す。
-
opts.
impressionCallersを impressionCallers に設定する。
-
-
-
その値を value とする。
-
value が 32 ビット符号なし整数範囲内の正の整数でない場合、 エラーを返す。
-
opts.
valueを value に設定する。
-
-
-
その値を maxValue とする。
-
maxValue が 32 ビット符号なし整数範囲内の正の整数でない場合、 エラーを返す。
-
opts.
maxValueを maxValue に設定する。
-
-
(opts, reportUrl) を返す。
-
アサート: url は潜在的に信頼できる URLである。
-
headers を、
"Content-Type"という名前を持ち、その値が "application/dap-report" であるヘッダーを含む、 新しいヘッダーリストとする。注:
AttributionAggregationProtocolがdap-18-histogram以外の値を得ることがあれば、これは更新する必要がある。 -
request を、次のプロパティを持つ新しいリクエストとする:
-
request をフェッチする。エラーが発生した場合は任意で再試行する。
5.3. Fetch monkey patch
-
request のdestinationが次のいずれでもない場合、 戻る:
"","audio","image","script","track","video". -
response のURLが潜在的に信頼できる URLでない場合、戻る。
-
request のclientから、 response のURLのオリジンを伴って、 暗黙の API 入力を取得する結果を implicitInputs とする。
-
implicitInputs が null の場合、戻る。
-
response のヘッダーリストから
`を取得する結果を saveImpressionHeader とする。Save-Impression` -
saveImpressionHeader が null でない場合:
-
response のヘッダーリストから
`を取得する結果を measureConversionHeader とする。Measure-Conversion` -
measureConversionHeader が null でない場合:
-
measureConversionHeader を解析する結果を parseConversionResult とする。
-
parseConversionResult がエラーでない場合:
-
HTTP-network fetch を次のように変更する:
includeCredentials が true の場合、ユーザーエージェントは request および response を与えて、レスポンスの
Set-Cookieヘッダーを解析して保存すべきである。
次の手順を追加する
-
request および response を用いて Attribution ヘッダーを処理する。
6. 実装上の考慮事項
-
次の値の管理および配布:
-
ヒストグラムサイズ
-
7. 集計
集計 サービスは、複数の attribution 情報を受け取り、 集計メトリクスを生成する。
ユーザーエージェント実装は、集計に関して異なる要件を持つ。 しかし、集計処理にはいくつかの共通要素がある。
第一に、ユーザーエージェントは、集計サービスに関する情報を 設定されているか、または他の方法で取得する必要がある。 これには、サポートされる集計方法と、 必要な任意の構成が含まれる。
各集計方法は、ヒストグラムがどのように次を行うかを 定義する必要がある:
-
集計用に準備される、
-
暗号化される、
-
必要なメタデータで注釈付けされる、および
-
集計のために集計サービスへ提出される。
集計方法は、サイトが集計結果をどのように取得するかも定義する必要がある。
7.1. マルチパーティ計算集計
マルチパーティ計算 (MPC)システムとは、複数の独立した主体が関与し、 合意された関数を協調して計算するシステムである。
この仕様は、Prio [PRIO] および Distributed Aggregation Protocol (DAP) [DAP] に基づく MPC システムを使用する。 これは二者 MPC システムであり、 入力に対するクライアント提供の正当性証明に依存することによって特徴付けられる。 これにより、システムへの提出サイズがやや増えるという控えめなコストで、 非常に効率的な MPC 動作が可能になる。
MPC を使用する集計サービスは、 定義済み関数を計算するために協調する、 二つ以上の独立したサービスから構成される。
MPC によって提供される基本的な保証は、 関数の定義済み出力と、明確に定義された漏洩のみが どの主体にも明らかにされるということである。
MPC の保証は、参加する主体の部分集合が正直である範囲でのみ成立する。 Prio で使用される二者 MPC では、 プライバシー、すなわち入力の機密性は、 いずれかの MPC オペレーターが正直であり続ける限り維持される。 この MPC 構成は、いずれかの MPC オペレーターによる 出力の破壊からは保護しない。
7.1.1. Prio および DAP
dap-18-histogram
集約メソッドは、Prio [PRIO]
および Distributed Aggregation Protocol (DAP) [DAP] を使用する。
具体的には、この集約メソッドは、
Prio3 Verifiable Distributed Aggregation Function (VDAF) [VDAF] の
Prio3L1BoundSum
インスタンス化 [PRIO-L1]
を使用する。
DAP および Prio3L1BoundSum インスタンス化は、レポートがどのように準備され、 暗号化され、集計のために提出されるかを定義する。 DAP はまた、集計がどのように取得されるか、 およびユーザーエージェントが集計サービスについて取得する必要のある構成を定義する。
Prio3L1BoundSum を 使用する場合、 レポートには分散ゼロ知識証明が含まれ、 MPC に参加するノードが、提出されたヒストグラムの合計が設定値未満であることを確認できる。 Prio3L1BoundSum は、 ヒストグラム合計が 2 の累乗より真に小さいことだけを検証できる。 つまり、証明は、正の整数値 n について 合計が 2n 未満であることを確認する。
レポートを構築するために、
証明は、maxValue
より大きい次の 2 の累乗である値に基づいて生成される。
これは、集計サービスが、
maxValue
と次の 2 の累乗の間のレポートを拒否できないことを意味する。
したがって、悪意のあるユーザーエージェントは、
集計ヒストグラムに maxValue
の最大 2 倍の値を寄与するレポートを生成する可能性がある。
証明は、maxValue
が 2n − 1 に等しい場合、
過剰な寄与の機会が存在しないことを保証する。
そのような攻撃の相対的影響は、他の制約が許す限り
maxValue
を 2n − 1 にできるだけ近く設定することで低減できる。
7.1.2. DAP 拡張
DAP への拡張 [DAP-ATTRIBUTION] は、このアプリケーションに必要である:
-
Collector identity (
collector_identity) は、集約の要求を担当するエンティティを識別する。 この拡張の値は、API 呼び出し元の識別情報を符号化する。 それは仲介 siteまたはconversion siteのいずれかである。 collector identity 拡張は DAP タスク全体に適用される。 -
Budget source (
budget_source) は、プライバシーバジェットを消費したエンティティを識別する。 この拡張の値は、conversion siteの識別情報を符号化する。 budget source 拡張は DAP タスク全体に適用される。 -
Privacy budget (
privacy_budget) は、集約サービスが、 集約タスクに設定されたものよりも少ないプライバシーバジェットしか 受け取っていないレポートを集約しないことを保証する。 privacy budget 拡張は各レポートに適用される。
ユーザーエージェントは、生成するレポートを構築するために これらの拡張を使用する。
7.1.3. DAP 用のレポート暗号化
undefined intermediarySite、
moment now、
およびリストである整数群
histogram が与えられ、
バイトシーケンス report を生成するものとして、
DAP
レポートを構築するには:
-
field を、 [VDAF] のSection 6.1.3 で定義される Field128 とする。
-
length を、 histogram のサイズとする。
-
maxValue を options の最大値とする。
-
chunkLength を、(Math.ceil(log2(maxValue + 1)) + 1) * length の平方根を 最も近い整数に丸めたものとする。
-
vdaf を、field、length、maxValue、および chunkLength を渡して作成される、 新しい PrioL1BoundSum VDAF [PRIO-L1] インスタンスとする。
-
microEpsilon を、options のepsilon に 1,000,000 を乗算し、正の Infinity 方向へ丸めたものとする。
-
caller を、intermediarySite が
undefinedでない場合は intermediarySite、 そうでなければ topLevelSite とする。 -
taskConfig を、 [DAP] のSection 4.2 で定義される
TaskConfigurationインスタンスを 次の値でエンコードすることにより生成されるバイト シーケンス群とする:-
空の
task_info。 -
DAP Leader の URL に設定された
leader_aggregator_endpoint。 これは、options.Aggregation Service における、選択された集約サービスの 実装定義の定義から取得される。 エンコードされた値は、設定された URL とfalse(フラグメントを除外するため)を用いて URL シリアライザーを呼び出すことにより生成される。 -
DAP Helper の URL に設定された
helper_aggregator_endpoint。 これは、options.Aggregation Service における、選択された集約サービスの 実装定義の定義から取得され、leader_aggregator_endpoint値と同じ処理を使用して生成される。 -
time_precision値 5。 -
min_batch_size値 20。 -
batch_mode値 TBD(Distributed Aggregation Protocol (DAP) Extensions for the Attribution API § batch-mode を参照)。 -
空の
batch_config。 -
vdaf_type値 7(A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions § dap を参照)。 -
length、maxValue、および chunkLength を用いて、 PrioL1BoundSum A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions § dap に従って エンコードされた
vdaf_configuration。 -
タスク拡張の集合
extensions。 これは、16-bit unsigned integers からバイトシーケンスへのマップである:-
Collector identity の拡張コードポイント。 caller のhost コンポーネントの シリアライズされた値にマップされる。
-
privacy budget source の拡張コードポイント。 topLevelSite のhost コンポーネントの シリアライズされた値にマップされる。
-
-
-
taskID を、 taskConfig を渡して Task Binding and In-Band Provisioning for DAP § task-id で説明される処理により生成されるバイト シーケンスとする。
-
ctx を、 [DAP] のSection 4.4.2.1 で定義されるように、 文字列
dap-18のエンコードされた値と taskID を連結して形成されるバイト シーケンスとする。 -
reportID を、暗号学的に安全なランダムソース [RFC4086] からサンプリングされた 16 バイトとする。
-
rand を、暗号学的に安全なランダムソース [RFC4086] からサンプリングされた 128 バイトとする。
-
publicShare、inputShares を、 [VDAF] のSection 4.1 で定義されるように、ctx、histogram、reportID(VDAF の "nonce" パラメーターとして)、 および rand を用いて、vdaf.
shard()を呼び出した結果とする。 -
time を、 Unix epoch から now までの期間を 5 秒のdurationで割り、 負の Infinity 方向へ丸めた結果の整数とする。
-
extensions を、 16-bit unsigned integers からバイトシーケンスへのマップであり、 次から構成されるものとする:
-
privacy budget の拡張コードポイント。 microEpsilon の値にマップされ、 UINT32、 値 microEpsilon、 および
false(isLittleEndian用)を用いてNumericToRawBytesを呼び出すことでエンコードされる。
-
-
reportMetadata を、reportID、time、および extensions から生成される、 エンコード済み DAP
ReportMetadataとする。 -
inputShares の各 share について反復し、 Section 4.4.2.1 で説明される、share を暗号化するための方法に従う:
-
pkR を、 options.Aggregation Service により示される集約サービスについて取得された、 集約サービス HPKE configuration からの対応するロールの公開鍵とする。
"dap-18-histogram" の URL は、 DAP Leader ロールを識別することが期待される。 実装は、両方の Aggregator について HPKE configuration を静的に取得する必要がある。 HPKE configuration はオンデマンドでフェッチしてはならない。 そのためにかかる時間が、
measureConversion()の呼び出し元へ 情報を漏洩するためである。 -
serverRole を、最初の項目(Leader)については 2、 2 番目(Helper)については 3 とする。
-
info を、次を連結して形成されるバイト シーケンスとする: 文字列
dap-18 input shareのエンコードされた値、 値 0x01 を持つバイト、および serverRole。 -
inputShareAAD を、
InputShareAadの構造に従い、 taskID、reportMetadata、publicShare、および taskConfig から構築する。 -
plaintextShare を、
PlaintextInputShareの構造に従い、 空の集合(private_extensions用)および share(payload用)から構築する。 -
hpke を、同じHPKE configurationに基づく HPKE [RFC9180] configuration とする。
-
encryptedShare を、pkR、info、inputShareAAD、および plaintextShare を渡して、 hpke.
Seal<mode_base>()を呼び出した結果とする。 -
encryptedShare を encryptedInputShares に追加する。
-
-
report を、reportMetadata、publicShare、 encryptedInputShares (2 つの値はそれぞれ leader および helper の暗号化された input share)、 および DAP aggregators から取得された集約サービス HPKE configuration から生成される、エンコード済み DAP
Reportとする。 -
report を返す。
7.2. 再生攻撃防止要件
ブラウザーにより生成されるコンバージョンレポートは、 レポートを要求した site により消費されたプライバシー バジェット の量に結び付けられる。
集約 サービスは、 同じレポートを複数回受け入れないことを保証しなければならない。
8. 差分プライバシー
この設計は、そのプライバシー設計の基礎として差分プライバシーの概念を使用する。 [PPA-DP]
差分プライバシーは、 システムによって明らかにされる私的情報の量を保証できる、 プライバシーの数学的定義である。 [DP] 差分プライバシーは、このシステムでプライバシーを保護する唯一の手段ではないが、 最も厳密に定義および分析されている。 そのため、最も強いプライバシー保証を提供する。
差分プライバシーは、集計データセットへの私的データの寄与を 隠すためにランダム化されたノイズを使用する。 ノイズの効果は、データセットへの個々の寄与を隠しつつ、 任意の集計分析の有用性を保持することである。
差分プライバシーを適用するには、 どの情報が保護されるかを定義する必要がある。 このシステムでは、保護される情報は、 単一のユーザーエージェント上の単一のユーザープロファイルについて、 単一のエポックにわたり、 コンバージョンを登録する単一の Web サイトに対する インプレッションである。 § 8.1 プライバシー単位では、この設計の含意を より詳しく説明する。
この attribution 設計は、 個別差分プライバシーと呼ばれる 差分プライバシーの一形式を使用する。 このモデルでは、ユーザーエージェントはそれぞれ、 寄与される情報を制限することを個別に保証する責任を負う。
この API の個別差分プライバシー設計には、 三つの主要な構成要素がある:
-
ユーザーエージェントは、コンバージョンレポートを通じてデバイスから出る インプレッションについての情報量を、 (プライバシーバジェットを使用して) 制限する。 § 8.2 プライバシーバジェットでは、これをより深く検討する。
-
集約 サービスは、任意のコンバージョンレポートが、 ユーザーエージェントによりそれに対して計上されたプライバシーバジェットに従ってのみ 使用されることを保証する。 § 7.2 リプレイ防止要件では、集約 サービスに対する要件を より詳細に説明する。
-
ノイズは集約サービスにより追加される。 § 8.3 差分プライバシーメカニズムでは、使用される可能性があるメカニズムを 詳述する。
これらの措置を合わせることで、各プライバシー単位について公開される情報に制限が課される。
8.1. プライバシー単位
差分プライバシーの実装には、 何が保護されるかについて明確な定義が必要である。 これはプライバシー 単位として知られ、 プライバシー保護を受ける主体を表す。
このシステムは、三つの値の組み合わせであるプライバシー単位を 採用する:
-
ユーザーエージェントプロファイル。 すなわち、単一の人物により使用されるユーザーエージェントのインスタンスである。
-
siteであって、 インプレッションについての情報を要求するもの(conversion site)。
インプレッションを登録する site(impression site)は 考慮されない。 それらの site は、このシステムから直接情報を受け取らない。
-
現在のエポック。
これらの値のいずれかが変化すると、新しい privacy unit が生成され、 その結果、別個のプライバシーバジェットが生じる。 人物が訪問する各 site は、各エポックについて 境界付けられた量の情報を受け取る。
理想的には、privacy unit は 単一の人物である。 理想的ではあるが、人物との完全な対応を保証する有用なシステムを開発することは、 いくつかの理由により不可能である:
-
人々は複数のブラウザーおよび複数のデバイスを使用し、 多くの場合、それらは調整されていない。
-
すべてのウェブサイトを対象とする単位は、 1 つの site により使い切られ、 他の site に一切の情報を与えない可能性がある。
-
広告は継続的な活動である。 新しいデータのためにプライバシーバジェットを割り当てない場合、 site はそのバジェットを永久に使い切ってしまう可能性がある。
8.1.1. プライバシー特性およびその限界の形式的分析
Attribution におけるプライバシー保護は多層的である:
-
サイトごとの予算は、任意の一つのコンバージョンサイトがユーザーについて学習できる量を制限する。
-
グローバル予算は、すべてのサイトがユーザーについて学習できる量に対する後方安全装置としての制限を提供する。
-
インプレッションサイトクォータは、コンバージョンサイトが任意の一つのインプレッションサイト上の ユーザーの活動について学習できる量を制限する。
-
各ユーザー行動の後に維持されるカウンターは、API にデータを保存できる、または API から学習できるサイト数を制限する。
この仕様における形式的プライバシー分析は、二つの論文に基づく。 一つ目 [PPA-DP] は、オンデバイスの個別 DP 会計の理論を確立する。二つ目 [PPA-DP-2] は、サイトごとの予算およびグローバル予算によって与えられる数学的プライバシー保証へ 分析を拡張する。
サイトごとの予算は、主要なプライバシー保護として捉えられるべきである。 サイトごとの予算は、意味のある DP 保証を提供するように構成されるべきである。 しかし、[PPA-DP-2] の分析では、これらの保証を制限する二つの仮定が特定された:
-
データ生成におけるサイト横断の適応性がないこと。 サイトの照会可能なデータストリーム (インプレッションおよびコンバージョン)は、他のサイトからの過去の DP attribution 結果とは独立に生成されなければならない。
-
サイト横断の共有制限を通じた漏洩がないこと。 一つのサイトからのクエリは、 他のサイトにどのレポートが発行されるかに影響してはならない。
要するに、どちらの仮定も実際には成立し得ない。
このシステムは、時間をかけて同じユーザーとインタラクションする可能性のある複数のサイトを含むため、 サイト横断の適応性がないという仮定が必要である。 サイトは、互いの DP 測定に基づいて、ユーザーに表示する広告を変更する。 たとえば、ある広告主がattribution 結果から、より良い広告を作る方法を学習した場合、 一部のユーザーは競合他社のサイトではなく、その広告主のサイトでコンバージョンする可能性がある。 この場合、あるサイトが学習した内容—そのサイト自身のサイトごとの予算にのみ計上される—は、 競合他社に見えるデータ(またはデータの欠如)を変化させるが、 これはそれらの競合他社のサイトごとの予算には計上されない。
継続的な測定を提供する任意のシステムはこの性質を持つため、 唯一の結論はこの制限を受け入れることである。 その制限は、グローバル DP 予算および共有クォータを持つことを正当化するものの一部であり、 それが二つ目の仮定につながる。
複数のサイトにまたがる共有制限がある場合、サイト横断の漏洩がないという仮定が必要である。 そのような共有制限の例として、グローバル DP 保証を提供することを目的とする グローバル安全制限がある。 一部のサイトからの measureConversion() 要求によって共有制限に 達した場合、他のサイトへのレポートが フィルターされる可能性がある。たとえば、あるサイトは、自分がインプレッションを持つことを知っている場合、 共有制限に達したかどうかについて何かを学習する。 この情報は集計されノイズが加えられているものの、予算を使い果たしたサイトに関する情報であり、 そのサイトのサイトごとの予算を超えるものである。
共有制限を通じた漏洩は、それらの制限を濫用を制限する手段としてのみ使用する動機となる。 共有制限をサイトごとの予算の大きな倍数として設定すると、 共有制限を悪用しようとするには、少なくともその数のサイトによる協調が必要になる。 倍数を大きくすると、共有制限はプライバシー保護の手段としては有用性が低くなり、 サービス拒否または類似の濫用形態から保護する手段としてより適したものになる。
対照的に、この分析は、グローバル予算を、これらの制限なしに 健全なグローバル個別 DP 保証を提供するよう実装できることを示している。 しかし、多数のサイトによる API の使用をサポートするには、 グローバル予算をサイトごとの予算のかなり大きな倍数として構成する必要がある。 これは、それが提供する DP 保証がどの仮定にも依存しない一方で、 単独では意味のある DP 保護を提供できないことを意味する。 したがって、サイトごとの予算が主要な DP 保証を提供する。 グローバル予算は、悪意のあるサイトによる協調攻撃の場合のフォールバックと見なすことができる。
グローバル DP 予算は、多数のサイトにまたがってユーザー識別情報をリンクし、 サイトごとの予算を結合できるサイトに対する防護にもなる。 サイトごとのモデルはこの可能性を考慮していないが、 一部のサイトがこの能力を持つことは一般的である。 特に、これにはアイデンティティプロバイダー、ユーザー識別子(メールアドレスや電話番号など)を 受け取るサイト、ナビゲーショントラッキング [NAV-TRACKING-MITIGATIONS] を 正常に使用するサイト、および何らかの理由でサイト横断 Cookie を使用できるサイト [WEB-WITHOUT-3P-COOKIES] が含まれる。 複数サイトにまたがって Attribution を使用することは、そのようなサイトにとって調整上の課題となり得るが、 活動を単一の人物にリンクする能力をサイトが持つ可能性は、 システムのプライバシーに関する包括的な分析において無視できない。
8.1.2. ブラウザーインスタンス
各ブラウザーインスタンスは、別個のプライバシー予算を管理する。
ブラウザーインスタンス間の協調は可能かもしれないが、 期待されてはいない。 その協調は、公開される情報の総量を減らすことで プライバシーを改善できる可能性がある。 また、一つのブラウザーインスタンス上のインプレッションを 別のブラウザーインスタンス上でコンバージョン可能にすることで、 attribution の有用性を改善する可能性もある。
異なる実装をまたぐ協調は、 現時点ではこの作業の範囲外である。 実装は、同じ人物のものとして知られているインスタンス間で 何らかの協調を行うことができるが、これは必須ではない。
8.1.3. サイトごとの制限
Web サイトへ公開される情報は、サイトを基準として行われる。 これは、他のプライバシー関連機能で使用される同じ境界に沿っている。
オリジンなど、より細かいプライバシー単位では、 追加情報を取得することが容易になる。 同じ人物に関する情報を複数のオリジンから収集できる。 その情報は、Cookie [COOKIES] などを用いて、 サイト内での情報の自由な流れを悪用することで結合できる。
§ 8.2.2 安全制限では、この制限を悪用する攻撃と、 それらの攻撃から保護するためにユーザーエージェントによって実装され得る追加の 安全制限について 議論する。
8.1.4. プライバシー予算エポック
サイトは、各プライバシー 予算エポック (またはエポック) に記録されたインプレッションを 照会するために使用される、別個の差分プライバシー予算を受け取る。
この予算は、ユーザーエージェントに登録され、後で照会される インプレッションに適用されるものであり、 コンバージョンには 適用されない。
分析 [PPA-DP] の観点からは、インプレッションの 各エポックは 別個のデータベースを形成する。 有限のプライバシー予算が、 各データベースに対して行われるすべてのクエリにわたって強制される。
複数のエポックにまたがるインプレッションからコンバージョン レポートを生成することには、プライバシー上の影響がある。 Web サイトへの単一の訪問により、そのサイトは多くのエポックにわたる活動について情報を得ることができる。 これには、その期間全体にわたって コンバージョンサイトが インプレッションの宛先として 識別されていることだけが必要である。 照会できるエポックの数は、ユーザーエージェントによって制限される。
目標は、実行可能な範囲でできるだけ大きなエポックを設定することである。 より長い期間は、任意の時点でサイトにより大きな総予算を割り当てられるため、 プライバシー/有用性のより良いバランスを可能にしつつ、 全体的なプライバシー損失率を低く保てる。 しかし、間隔が長くなると、プライバシー予算を完全に使い果たしやすくなり、 次の更新まで情報が得られなくなる。
エポック期間を 1 週間に設定するという決定は、 おおむね任意である。 1 週間は、将来数日または数週間に起こり得る変化を考慮した慎重な計画なしに、 サイトがプライバシー予算の使い方を決定する柔軟性を持つのに 十分であると期待される。
§ 8.2 プライバシー予算では、予算管理の処理をより詳しく説明する。
8.2. プライバシー予算
ブラウザーはプライバシー 予算を維持する。 これは、プライバシー損失の量を制限するための手段である。
この仕様は、その基礎として (ε, δ)-差分プライバシーの個別形式を使用する。 このモデルでは、プライバシー損失は ε の値を用いて測定される。 δ の値は、集計にノイズを追加するときに集計サービスによって扱われる。
各ユーザーエージェントインスタンスは、 プライバシー予算を管理する責任を負う。
要求される各コンバージョンレポートは、 そのレポートが消費するプライバシー予算の量を表す ε 値と、 コンバージョンレポートで返され得る値の最大値を指定する。
8.2.1. プライバシー予算の控除
コンバージョンレポートのためにインプレッションを 探索するとき、 ユーザーエージェントは、それらのインプレッションが保存されたプライバシー予算エポックの予算から、 指定された ε 値を控除する。 そのエポックの プライバシー予算が 十分でない場合、 そのエポックからのインプレッションは使用されない。
コンバージョン サイトが measureConversion() を呼び出すたびに、 attribution ロジックがインプレッションを選択した エポックについて、 プライバシー予算が控除される。
コンバージョン レポートは、"now" と記された時点で要求される可能性がある。 そのコンバージョンレポートは、黒い円で示されたインプレッションを選択し、 Sites B、C、および E からのインプレッションに対応する。
その結果、conversion site のプライバシー バジェットは、 エポック 1、3、4、および 5 から差し引かれる。 エポック 2 にはインプレッションが記録されていなかったため、 そのエポックからバジェットは 差し引かれない。
ユーザー エージェントがプライバシーバジェットの枯渇をどのように管理するかは、 選択されたattribution logicに依存する。
8.2.2. 安全制限
基本的なプライバシー単位は、 複数のサイトにまたがって同じ人物の活動を相関できる敵対者による攻撃に対して脆弱である。
サイトのグループは、共有所有権や強い合意がある場合など、 その活動を協調できることがある。 特定の訪問者が同じ人物であることを、FedCM [FEDCM] のようなものを含む任意の手段で 確信できるサイトのグループは、 この API から得た情報を結合できる。
これは、協調が発生するサイト数に比例して、 サイトが attribution から情報を得る速度を高めるために使用できる。 デフォルトのプライバシー単位は、 この方法で公開される情報に制限を設けない。
この影響に対抗するため、ユーザーエージェントは安全制限を実装できる。 これは、サイトを考慮しない追加のプライバシー予算である。 安全制限は、ほとんどの通常の閲覧活動では到達しないように、 サイトごとの予算より大幅に高く設定される場合がある。 目標は、集中的な活動または攻撃を受けている場合にのみ 有効になるようにすることである。
サイトごとのプライバシー予算と同様に、 コンバージョンレポートの要求が 安全制限を超過させたかどうかをサイトが判断できないことが重要である。
8.3. 差分プライバシーメカニズム
差分プライバシーメカニズム、すなわちノイズを追加する具体的な方法は、 集約 サービスにより選択できる。
ラプラスノイズを追加することは、 ノイズ全体の大きさと、 実装および分析の単純さとのバランスを取り、 良好な結果を生むことが期待される。 現在の設計は L1 ノルムに基づく DP 感度を使用しており、 集約で追加されるラプラスノイズをサポートする。 他のノイズメカニズムをサポートするには、 感度の計算および通知の方法に追加の変更が必要になる可能性がある。
これらの集約サービスのいずれについても定義されるように、 中央の場所でノイズを追加することにより、 レポートの総数が増加しても、 ノイズの総量が増加しないことが保証される。 これは、レポートが生成される時点でノイズを適用する 差分プライバシー設計 (すなわち、ローカル差分プライバシーモデル)に比べて、 有用性上の利点を提供する。 そのような設計では、ノイズはレポートの総数に比例して増加する。
9. セキュリティ考慮事項
9.1. インプレッションストア
Attribution API によって使用されるインプレッションストアは、 閲覧活動に関連する情報を保持し、 閲覧セッションをまたいで永続する。 インプレッションストアを通じる情報の流れは 厳格に制御されているが、 オリジンをまたいで一定量の情報を運ぶ。
次の措置により、インプレッションストアを通じた有害な情報フローの可能性が制限される:
-
Web サイトはインプレッションストアから読み取ることができない。 インプレッションストアからの情報は、 暗号化されたコンバージョンレポートを通じてのみ公開される。 差分プライバシーは、ユーザーエージェントおよび 集計サービス内の機能の組み合わせによって提供され、 集計サービスが出力する集計情報が、 任意のユーザーの寄与がない場合の値と区別できる確率に対して、 厳密な境界を提供する。
-
ユーザーは、保存されたインプレッションを明示的に 消去できる。
-
ユーザーエージェントは、明示的なユーザー操作がない場合でも、 lifetimeDays の最大値を課すことにより、 データがインプレッションストア内に永続できる期間を制限することが推奨される。
9.2. 実装におけるサイドチャネルリスク
Attribution API は、必要なセキュリティおよびプライバシー特性を維持するために、 注意して実装されなければならない。 API を呼び出すサイトは、次を知ることができない:
-
Attribution API が有効であるかどうか。
-
attribution が発生したかどうか。
-
プライバシー 予算が枯渇しているかどうか。
-
コンバージョンレポートが非ゼロの コンバージョン 値を反映しているかどうか。
-
どの histogramIndex に コンバージョン値が割り当てられるか。
明示的な返り値や投げられる例外だけが、 サイトが Attribution API から情報を得る手段ではないことに注意。 次のようなサイドチャネルから、 センシティブな情報を推論できる可能性がある:
-
API が完了するまでに要する時間の変動。
-
API による、メモリ、ストレージ、ネットワーク、CPU などの共有リソースの消費。 これには、その消費に対する任意の制限の強制が、 サイトから観測可能である場合、それも含まれる。
API 内の関数の実行時間の変動は、 保証を維持するうえで主な考慮事項である。 実行時間について特に懸念される要因は二つある:
-
measureConversion() が処理する インプレッションの数。 サイトは保存されるインプレッションの数と、それらを選択するロジックを制御するため、 これは、サイト横断タイミングサイドチャネルを作成する大きな露出をサイトに与える。
-
共有グローバル状態へのアクセス。 API への同時アクセスは、正しさの誤りから保護するため、 単一のattribution budget lockによって制御される。 そのロックは、API に同時アクセスするサイト間の情報漏洩手段を作成する。
グローバルプライバシー予算ストア、 インプレッションサイトクォータストア、 およびエポック開始時刻内の 共有グローバル状態は、それらの値がアルゴリズムの実行時間に直接影響しないため、 リスクは低い。 実装は、それでも、任意のグローバル状態が フィンガープリントやその他の情報漏洩に 寄与しないことを保証する必要がある。
すべてのサイドチャネルを完全に除去することは現実的ではないが、 実装は attribution API からセンシティブ情報が漏洩するのを防ぐため、 合理的な努力を行わなければならない。 漏洩を防ぐ戦略には次が含まれる:
-
API が無効である場合でも、すべての API 入力を完全に検証すること。
-
条件付きロジックを避けること。たとえば、 measureConversion() は、報告されるコンバージョン値がゼロである場合でも、 常にコンバージョンレポートを構築する完全な処理を通るべきである。
-
特定の操作に固定の実行時間を設定すること。
9.3. 集計サービス
Web プラットフォームの一部ではないが、 集計サービスのセキュリティは Attribution 機構全体のセキュリティにとって非常に重要である。 measureConversion() によって生成される コンバージョンレポートは、 集計サービスの暗号鍵を用いて暗号化される。 したがって、これらのレポートに含まれる情報が開示される可能性の多くは、 集計サービスの詳細に依存する。
ユーザー エージェント開発者は、 Attribution API のサポート対象サービスとして追加する前に、 集計サービスの設計と、集計サービス運用者の信頼性を慎重に検討すべきである。 これらの問題に関する追加の議論は、 § 7 集計および§ 10 プライバシー考慮事項にある。
9.4. 複数サイトからのレポートの結合
Attribution API におけるプライバシーメカニズムは、 主にsiteの粒度で動作する。 悪意ある運用者は、 複数の site についてインプレッションを 登録しようと試みる可能性があり、 それにより attribution を通じて本来解放される情報量を 超過する。 § 8.2.2 安全制限では、この可能性を緩和するための追加のクロスサイト プライバシーバジェットの確立について説明する。
9.5. 広告詐欺
多くの技術と同様に、 Web 上の広告はさまざまな種類の詐欺の対象となってきた。
インプレッションの不正な登録は、 Attribution API において特に懸念される。 インプレッションはデバイス上にのみ保存されるためである。 不正なインプレッションを識別して attribution から除外するために、 サーバー側の知見を適用することはできない。 逆に、コンバージョンレポートは暗号化されているものの、 レポートはサーバーに送信されるため、 サーバーはコンバージョンが不正である可能性が高いと判断し、 集計から除外できる。
Attribution API の悪意ある使用に対する重要な緩和策は、 インプレッションを登録する際に適格なコンバージョンサイトを明示的に指定し、 コンバージョンを登録する際に適格なインプレッションサイトおよびヒストグラムインデックスを明示的に指定することである。 これにより、任意の悪意あるサイト上のインプレッションが、 意図された候補インプレッション集合への attribution に干渉することを防ぐ。
10. プライバシー考慮事項
この API の主なプライバシー目標は、 サイトに attribution を実行する能力を提供することが、 サイト横断認識を実行する能力を向上させないことを保証することである。
この節は、この目標を達成するために必要な保護について、 より多くの情報を提供する。 追加の議論では、同一サイト認識の防止など、 二次的なプライバシー目標について述べる。
10.1. Attribution API によって公開される情報
インプレッションストアおよび プライバシー予算 ストアは、 閲覧活動の断面に関する情報を含む。 API の使用が増えるにつれて、 この情報の範囲も広がる。 しかし、これらのストアに書き込まれる情報の大半は 決して開示されない。 attribution はデバイス上で実行されるため (オンデバイス attribution)、 attribution されたコンバージョンに関する情報のみが Attribution API によって公開される。 これは、インプレッションとコンバージョンの両方に関する情報が、 オフデバイス attributionのために集計サービスへ送信される 他の方式とは対照的である。 後者の種類の方式では、集計サービスの侵害 (または集計サービスとの通信の侵害)において明らかになり得る情報量が 大幅に大きい。
Attribution API が attribution を行う場合、 その attribution に関する情報は、 差分プライバシーの制約が許す範囲でのみ、 デバイスから公開される。
Attribution API は、比較的まれなコンバージョンイベントと、 関連する限定されたインプレッション候補集合との関連を測定することを意図しているが、 API が大規模なデータ収集にどのように悪用され得るかを考慮することが重要である。 インプレッションが可能なコンバージョン サイトを列挙する(およびその逆)という要件は、 API の大量データ収集への悪用を防ぎ、 そのような悪用の試みをより可視化するうえで重要な役割を持つ。
10.2. Attribution API の無効化
ユーザーエージェントは、ユーザーが Attribution API を無効にするための制御を提供しなければならない。
Attribution API は、集計情報のみを明らかにするよう設計されている。 差分プライバシーの使用は、 特定のユーザーが集計出力に寄与したかどうかを判定できる可能性を制限する。 しかし、一部のユーザーはそれでも attribution 測定に参加したくないと考える場合がある。
実装は、Attribution API 専用の制御、 または複数の機能に適用される統合プライバシー制御を用いて、 ユーザーにオプトアウトの選択肢を提供できる。
ユーザーエージェント開発者は、 他のプライバシーモードと Attribution API との相互作用を考慮すべきである。 たとえば、attribution はプライベートブラウジングモードで無効化される場合や、 ユーザーが診断データの収集をオプトアウトしている場合に無効化される場合がある。
設計上、ユーザーがオプトアウトしているかどうかは Web サイトから検出できない。
フィンガープリンティングのリスクを最小化し、 Attribution API を無効にすることを選択したユーザーへの差別を防ぐため、 サイトは API が無効であることを検出できてはならない。 具体的には、それ以外の点で有効な Attribution API へのすべての呼び出しは、 API が無効であっても正常に完了する。 挙動の唯一の違いは、API が無効であるときに返される コンバージョン レポートが、いかなるコンバージョン値も報告しないことである。 レポートは暗号化されているため、 この違いはコンバージョンレポートを受け取るサイトから検出できない。
10.3. 可視性
実装は、ユーザーがインプレッションストアの状態を表示し、 過去のレポート提出を確認する方法を提供すべきである。
これらのインターフェイスは、 サイトによる Attribution API の集計使用を示す要約情報に限定される場合がある。 インプレッションおよび提出済みレポートの詳細を調べるためのインターフェイスは、 ユーザーと Web 開発者の両方による API の動作診断を可能にし得る。
10.4. 未構成のブラウザー
この API は、ユーザーエージェントインスタンスが、 measureConversion() への要求に応答するために 必要なすべての構成を持っていることを前提とする。
aggregation service の構成のうち、 measureConversion() を呼び出すために必要なものが存在しない、または古くなっている場合、 それはサイトから観測可能になりうる。
構成の取得が measureConversion() の呼び出しの解決を遅延させうる場合、 これはタイミングサイドチャネルを作り出す。 代わりに偽の応答が生成される場合、 適切に構成されたユーザーエージェント からの応答と偽の応答との差異が 観測可能になることがある。 これは、キー識別子や その他の暗号化されていないメタデータの使用である可能性がある。 暗号文の長さの違いも、暗号化される内容の変化や アルゴリズム選択の変化を明らかにしうる。
古い、または存在しない構成を検出することは、 フィンガープリントするために、 ユーザーエージェントに対して使用される可能性がある。
したがって、ユーザー エージェントは、 サイトから観測できない方法で、aggregation service 構成の取得を優先すべきである。 これは、コンテンツの読み込みを開始する前に、 起動時に構成を取得することで達成できる可能性がある。
必要な構成を取得できない場合、 または明らかに古くなっている場合、 実装は measureConversion() が呼び出されたときに ただちに却下することを選択してもよい。 これは情報を漏えいするが、 偽の値を生成しようとするよりも漏えいが少ない可能性がある。
10.5. 保存済みインプレッションへの識別情報の含有
サイトは、
matchValue
または他のフィールドを使用して、
インプレッション内に一定量のデータをエンコードできる。
API は、サイトがこれらのフィールドにユーザー識別子をエンコードすることを防がない。
attribution 処理は、
コンバージョンレポートを構築する際にこのデータを使用でき、
これは、その識別情報がそのレポートを受け取るサイトに利用可能になる
一定のリスクを意味する。
次の措置がこのリスクを軽減する:
-
インプレッション ストアは直接読み取れない。 したがって、識別子は、それらに関する情報が コンバージョンレポートで明らかにされる範囲でのみ、 トラッキングに使用可能である。
-
コンバージョンレポート内の情報は、 集計およびノイズの追加後にのみ明らかにされる。
-
ユーザーはインプレッションストアを消去する能力を持つ。
-
Attribution API が無効である場合、 インプレッションはインプレッションストアに保存されない。
10.6. サードパーティコンテキストでの使用
Attribution API は、サードパーティコンテキストでも利用可能である。 特に、サードパーティ iframe は saveImpression() を呼び出せる。 ただし、インプレッションは iframe のオリジンではなく、 トップレベルナビゲーションコンテキストのサイト で記録されることに注意すること。
サードパーティコンテキストで API が利用可能であることは、 プライバシーリスクの一定の増加を伴うが、 iframe は広告表示に一般的に使用されるため、 このサポートは必要と見なされる。
10.7. API 状態の消去
ユーザー エージェントは、ストレージを消去する選択肢を提示する可能性がある。 これらは 2 つの理由で存在する:
-
site に対するプライバシー。 これにより、それらの site は将来のインタラクションでユーザーを認識できなくなる (すなわち、same-site recognitionを防ぐため)。
-
アクティビティの痕跡をローカルで削除すること。 これにより、コンピューターの他のユーザーが 閲覧履歴にアクセスできなくなる。
プライバシーバジェットの支出を追跡する状態を消去すると、 site に対するプライバシーに悪影響がある。 その場合、site は attribution からより多くの情報を得られるようになる。
ユーザー エージェントは、API が無効化されたとき、 プライバシー バジェットストアおよびエポック開始時刻から データを消去してもよい。 その場合、API が再び有効化されても、 API が無効化される前に どのバジェットが消費されたかを判断する方法はない。 その場合、ユーザーエージェントは、 last browsing history clearの値を更新して、 プライバシー バジェットが意図せず超過されないようにできる。
10.7.1. サイトデータの消去
ユーザーの要求により site データを消去するが、 閲覧履歴を保持する場合、 ユーザー エージェントは、 影響を受けるsiteの 集合、 false(forgetVisits 用)、 およびその操作が行われた時刻が与えられたものとして、 attribution 用に閲覧履歴を消去するを呼び出す。 これは、その site のプライバシーバジェットをゼロに設定し、 その site でのコンバージョン測定の使用を防ぐ。 これは、保存されたインプレッションをインプレッションストアから削除しない。 論理的には、インプレッションは保存された時点でconversion siteへ移転される。
siteの要求により、
`Clear-Site-Data`
ヘッダーを使用して site データを消去する場合、
ユーザー
エージェントは、
プライバシーバジェットストア
またはエポック開始
時刻を変更することなく、
インプレッションを削除するだけである。
10.7.2. 閲覧履歴の消去
閲覧履歴を消去する場合、 プライバシー バジェットストアを更新するだけでは不十分である。 site に対するプライバシー喪失を防ぐために必要な siteごとの 情報を保持すると、 コンピューターの他のユーザーが発見できる site への訪問に関する情報が残る。
閲覧履歴を消去するユーザーエージェントは、 影響を受けるsiteの 集合、 true(forgetVisits 用)、 およびその操作が開始された時刻が与えられたものとして、 attribution 用に閲覧履歴を消去するを呼び出す。
閲覧履歴を消去する場合、 ユーザー エージェントは、 siteごとのすべてのプライバシーバジェット情報を 削除する必要がある (すなわち、プライバシーバジェットストアからエントリーを削除する)。 ユーザー エージェントはまた、 その情報を失った結果として、 その後のプライバシー バジェット支出が、 設定された制限を超えるプライバシー喪失を引き起こせないことを保証する必要がある。
これは、閲覧履歴が破棄されたエポックについて、 attribution を無効化することで達成できる。 そうしない場合、履歴の消去の直前に バジェットを消費したsiteは、 状態の消去がない場合よりも多くを API を通じて知ることができる。
これは、影響を受けるsiteについて、 エポックの残りの期間 API を無効化する。 エポック開始 時刻は消去されないため、 エポックの タイムラインは連続したままである。
ユーザー エージェントは、履歴が最後に消去された時刻を last browsing history clear値に記憶する。 これは、siteが、 ユーザー エージェントが選択した最大許容プライバシーバジェットを超過できないことが保証されるまで、 バジェットの支出を防ぐために使用される。
attribution の開始エポックを取得する アルゴリズムは、 conversion siteが、 状態が消去された時点から 1 エポック duration以内に 開始するいずれのエポックからも、 インプレッションを照会できないことを保証する。
10.7.3. インプレッションの消去
インプレッションストアを消去するための仕組みを提供しなければならない。 たとえば、Attribution API を無効化するコントロールが アクティブ化されたときに、 インプレッションストアを消去できる。
ユーザーエージェントが 保存済みデータ(履歴、Cookie など)を消去するために提供する任意の仕組みは、 インプレッションストアにも適用されるよう拡張することが推奨される。 § 10.7 API 状態の消去は、保存済みデータの消去について より詳細な情報を提供する。
ユーザー エージェントがsiteの状態を消去する場合、 影響を受ける期間中に保存されたすべての保存済み インプレッションのうち、 一致するimpression site またはconversion siteを持つものを 破棄しなければならない。 impression siteについては、 これらのインプレッションは 消去されたアクティビティに関係する。 状態が消去されたconversion siteは、 これらのインプレッションを使用できない。
インプレッションのうち、一致する intermediary siteを持つものは、 保持されてもよい。
10.8. 時計の選択
この API は、時刻の基盤として壁時計を使用する。 これは主に、この API が永続的な時刻の概念に依存するためである。 単調時計は、ユーザー エージェントの単一の実行中にのみ定義されるため、 ユーザーエージェントが再起動された場合、 一貫性の保証がない。
壁時計は、時計のドリフトにより蓄積し得る誤差を考慮して 調整できる。 したがって壁時計は、常に一貫した速度で進むことは保証されず、 場合によっては減少する可能性もある。
壁時計の減少は、 この API が提供するプライバシー保証に影響しない。 時計の増加のみが、 プライバシーに悪影響を及ぼし得る。 時間の通常の進行を超える増加は、 プライバシーバジェットが 意図より早く更新される結果をもたらす可能性がある。
各エポック内で補正を受ける時計については、 時計の調整はプライバシー上の影響を持たない。 十分に大きい単一の補正は、 プライバシー バジェットを予定より早く更新させ、 プライバシー喪失の一回限りの増加をもたらす可能性がある。 継続的な大きな補正は、プライバシーに最も深刻な影響を及ぼす。 各エポック間の遷移により、追加のプライバシーバジェットが解放されるためである。
時刻が非常に大きく増加し、 エポック全体をスキップしても、 追加のプライバシー喪失は生じない。 インプレッションを保存できない限り、 プライバシー喪失は起こり得ない。
もちろん、時計に対する大きな補正または継続的な補正を必要とする ユーザーエージェントは、 それが報告する時刻の結果として、 高い識別可能性を持つ可能性が高い。 それだけで、望ましくないcross-site recognitionを可能にするには十分である可能性が高い。
11. 謝辞
この仕様は、多くの人々による多大な作業の成果である。 このレベルの API の大まかな形は、Luke Winstrom のアイデアに基づいている。 プライバシーアーキテクチャは、[PPA-DP] の著者らによるものである。