From 9b5acdc80bcb6019965e407aa87e623ef78fc16b Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Wed, 15 Nov 2023 15:24:23 -0600 Subject: [PATCH 1/8] Update flexible_event_config.md --- flexible_event_config.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/flexible_event_config.md b/flexible_event_config.md index 2420b109f7..b41134263d 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -169,6 +169,17 @@ When the `event_report_window` for a spec completes, we will map its summary val "trigger_summary_bucket": [, ] } ``` +### Trigger prioritization + +Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work: + +1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending) +2. Whenver a spec's window's end time is hit (breaking ties arbitrarily) + 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. + 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. + 3. Erase all of the triggers associated with the current spec and window. + +TODO: this algorithm is simple, but we should consider whether we want to add a carve-out to greedily apply any trigger that updates internal state but does not generate a report (i.e. just increments value within a summary bucket). This may improve utility at a complexity cost. ### Trigger-data modulus matching example From 89312559a8c919e500b3db0b15d239360ab7bd07 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Wed, 15 Nov 2023 15:26:40 -0600 Subject: [PATCH 2/8] Update flexible_event_config.md --- flexible_event_config.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index b41134263d..4e84bd374e 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -9,6 +9,7 @@ _Note: This document describes possible new functionality in the Attribution Rep - [Goals](#goals) - [Phase 2: Full Flexible Event-Level](#phase-2-full-flexible-event-level) - [API changes](#api-changes) + - [Trigger prioritization](#trigger-prioritization) - [Trigger-data modulus matching example](#trigger-data-modulus-matching-example) - [Configurations that are equivalent to the current version](#configurations-that-are-equivalent-to-the-current-version) - [Equivalent event sources](#equivalent-event-sources) @@ -175,9 +176,9 @@ Given that triggering attribution can affect a source's state without producing 1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending) 2. Whenver a spec's window's end time is hit (breaking ties arbitrarily) - 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. - 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. - 3. Erase all of the triggers associated with the current spec and window. + 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. + 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. + 3. Erase all of the triggers associated with the current spec and window. TODO: this algorithm is simple, but we should consider whether we want to add a carve-out to greedily apply any trigger that updates internal state but does not generate a report (i.e. just increments value within a summary bucket). This may improve utility at a complexity cost. From 4c541a8d859df1c17858d49fbd948b53823c0ea5 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Wed, 15 Nov 2023 15:38:36 -0600 Subject: [PATCH 3/8] Remove TODO --- flexible_event_config.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index 4e84bd374e..99c362c072 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -180,8 +180,6 @@ Given that triggering attribution can affect a source's state without producing 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. 3. Erase all of the triggers associated with the current spec and window. -TODO: this algorithm is simple, but we should consider whether we want to add a carve-out to greedily apply any trigger that updates internal state but does not generate a report (i.e. just increments value within a summary bucket). This may improve utility at a complexity cost. - ### Trigger-data modulus matching example Given a source with the following registration: From 7dd5563413af5531e982309d3a770315f3929019 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Wed, 15 Nov 2023 16:27:46 -0600 Subject: [PATCH 4/8] Update flexible_event_config.md Co-authored-by: Andrew Paseltiner --- flexible_event_config.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index 99c362c072..b427f247d9 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -177,7 +177,7 @@ Given that triggering attribution can affect a source's state without producing 1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending) 2. Whenver a spec's window's end time is hit (breaking ties arbitrarily) 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. - 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. + 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. 3. Erase all of the triggers associated with the current spec and window. ### Trigger-data modulus matching example From 01fdce3d540758240f8b9528330c2f5efc5f5368 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Wed, 15 Nov 2023 16:33:28 -0600 Subject: [PATCH 5/8] Update flexible_event_config.md Co-authored-by: Andrew Paseltiner --- flexible_event_config.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index b427f247d9..af0be9bfbc 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -175,7 +175,7 @@ When the `event_report_window` for a spec completes, we will map its summary val Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work: 1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending) -2. Whenver a spec's window's end time is hit (breaking ties arbitrarily) +2. Whenever a spec's window's end time is hit (breaking ties arbitrarily): 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. 3. Erase all of the triggers associated with the current spec and window. From ec39b2b649b7f58790f4f55540e19f3e778bd648 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Wed, 15 Nov 2023 20:10:22 -0600 Subject: [PATCH 6/8] Update flexible_event_config.md --- flexible_event_config.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index af0be9bfbc..d36698eef1 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -174,11 +174,11 @@ When the `event_report_window` for a spec completes, we will map its summary val Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work: -1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending) -2. Whenever a spec's window's end time is hit (breaking ties arbitrarily): - 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. +1. For every source, maintain a list of triggers, sorted in order of priority (descending), then trigger time (ascending) +2. At the end of any report window (across all of a source's specs, breaking ties arbitrarily): + 1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. - 3. Erase all of the triggers associated with the current spec and window. + 3. Erase all of the triggers associated with the current spec and window from the source's trigger list ### Trigger-data modulus matching example From 694eb067a4cb5a06c92e15088fbc8c2c31fd94a0 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Thu, 16 Nov 2023 09:54:50 -0600 Subject: [PATCH 7/8] Update flexible_event_config.md --- flexible_event_config.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index d36698eef1..413a174661 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -177,7 +177,7 @@ Given that triggering attribution can affect a source's state without producing 1. For every source, maintain a list of triggers, sorted in order of priority (descending), then trigger time (ascending) 2. At the end of any report window (across all of a source's specs, breaking ties arbitrarily): 1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. - 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. + 2. Send all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. Delete all of the speculative reports that are not scheduled to be emitted in this window. 3. Erase all of the triggers associated with the current spec and window from the source's trigger list ### Trigger-data modulus matching example From ebeee6923a66c106f12cda918eb891af4f0f5807 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Thu, 16 Nov 2023 09:58:48 -0600 Subject: [PATCH 8/8] Update flexible_event_config.md --- flexible_event_config.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/flexible_event_config.md b/flexible_event_config.md index 413a174661..28b257e07c 100644 --- a/flexible_event_config.md +++ b/flexible_event_config.md @@ -176,9 +176,11 @@ Given that triggering attribution can affect a source's state without producing 1. For every source, maintain a list of triggers, sorted in order of priority (descending), then trigger time (ascending) 2. At the end of any report window (across all of a source's specs, breaking ties arbitrarily): - 1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. - 2. Send all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. Delete all of the speculative reports that are not scheduled to be emitted in this window. - 3. Erase all of the triggers associated with the current spec and window from the source's trigger list + 1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop whenever privacy limits are hit. + 2. Send all of the speculative reports that are scheduled to be emitted in the current window + 3. Update the source's total value per trigger data, and total # of event-level reports based on all of the triggers that were successfully applied in the current window. + 4. Delete all of the speculative reports that are not scheduled to be emitted in this window. + 5. Delete all of the triggers associated with the current spec and window from the source's trigger list ### Trigger-data modulus matching example