Update algorithm for budget deduction #28
Conversation
|
@martinthomson updated this PR to also only specify the L1-norm instead of p-norm. |
|
@martinthomson can we go ahead and merge this PR? I think this is probably good for the budget section for now -- keeping it aligned with the L1 case of the paper. |
| @@ -6,7 +6,8 @@ URL: https://private-attribution.github.io/api/ | |||
| Editor: Martin Thomson, w3cid 68503, Mozilla https://mozilla.org/, [email protected] | |||
| Editor: Andy Leiserson, w3cid 147715, Mozilla https://mozilla.org/, [email protected] | |||
| Editor: Benjamin Savage, w3cid 114877, Meta https://www.meta.com/, [email protected] | |||
| Abstract: This specifies a browser API for the measurement of advertising performance. The goal is to produce aggregate statistics about how advertising leads to conversions, without creating a risk to the privacy of individual web users. This API collates information about people from multiple web origins, which could be a significant risk to their privacy. To manage this risk, the information that is gathered is aggregated using an aggregation service that is trusted by the user-agent to perform aggregation within strict limits. Noise is added to the aggregates produced by this service to provide differential privacy. Websites may select an aggregation service from the list of approved aggregation services provided by the user-agent. | |||
| Editor: Benjamin Case, w3cid 128082, Meta https://www.meta.com/, [email protected] | |||
| Abstract: This specifies a browser API for the measurement of advertising performance. The goal is to produce aggregate statistics about how advertising leads to conversions, without creating a risk to the privacy of individual web users. This API collates information about people from multiple web origins, which could be a significant risk to their privacy. To manage this risk, the information that is gathered is aggregated using an aggregation service that is trusted by the user-agent to perform aggregation within strict limits. Noise is added to the aggregates produced by this service to provide differential privacy. Websites may select an aggregation service from the list of approved aggregation services provided by the user-agent. | |||
There was a problem hiding this comment.
What diff tool are you using? You didn't change this line, but GitHub seems to think that you did...
| When a conversion requests attribution the call includes several querier-provided | ||
| parameters: |
There was a problem hiding this comment.
| When a conversion requests attribution the call includes several querier-provided | |
| parameters: | |
| When a site requests attribution, they provide several parameters: |
| the impressions from that week are not used. | ||
| When a conversion requests attribution the call includes several querier-provided | ||
| parameters: | ||
| 1. the window of epochs to search for relevant events (`epochs` parameter); |
There was a problem hiding this comment.
| 1. the window of epochs to search for relevant events (`epochs` parameter); | |
| 1. the length of time over which to select impressions ({{PrivateAttributionConversionOptions/lookbackDays}}); |
| When a conversion requests attribution the call includes several querier-provided | ||
| parameters: | ||
| 1. the window of epochs to search for relevant events (`epochs` parameter); | ||
| 2. the requested privacy budget (`requested_epsilon`); |
There was a problem hiding this comment.
| 2. the requested privacy budget (`requested_epsilon`); | |
| 2. the requested [=privacy budget=] ({{PrivateAttributionConversionOptions/epsilon}}); |
| parameters: | ||
| 1. the window of epochs to search for relevant events (`epochs` parameter); | ||
| 2. the requested privacy budget (`requested_epsilon`); | ||
| 3. the `filterData` value used for selecting relevant events; |
There was a problem hiding this comment.
| 3. the `filterData` value used for selecting relevant events; | |
| 3. the {{PrivateAttributionConversionOptions/filterData}} value used for selecting relevant events; |
| 1. the window of epochs to search for relevant events (`epochs` parameter); | ||
| 2. the requested privacy budget (`requested_epsilon`); | ||
| 3. the `filterData` value used for selecting relevant events; | ||
| 4. the `PrivateAttributionLogic` such as last-touch or equal-credit; |
There was a problem hiding this comment.
| 4. the `PrivateAttributionLogic` such as last-touch or equal-credit; | |
| 4. the attribution {{PrivateAttributionConversionOptions/logic}} to use in selecting and attributing credit; |
| 5. two sensitivity parameters: `report_global_sensitivity` which is a cap on how much attributed | ||
| value can come from this one conversion (e.g. the conversion value) and `query_global_sensitivity` | ||
| which is a maximum sensitivity across all reports to be processed the aggregation query. |
There was a problem hiding this comment.
This doesn't match the terminology that we've described. What we have defined has a value and a maxValue. It would help if you used the same words.
I don't regard the value as being sensitivity measure in that way, either. I view the sensitivity as a measure that applies to the entire query. That's a measure that is supplied when a batch of reports is sent to the aggregation service. Individual reports will have a maxValue that the browser will guarantee is at least as much as the actual contained value and no greater than the batch sensitivity. The concrete budget deduction will be no higher than both these measures.
| which is a maximum sensitivity across all reports to be processed the aggregation query. | ||
|
|
||
| The algorithm to <dfn>deduct privacy budget</dfn> and compute the attributed histogram will first look across | ||
| epochs for eligible impressions. It will deduct budget from any epoch with eligible |
There was a problem hiding this comment.
I'd rather not use the word "epoch" here if we're going to use "week" elsewhere.
| Step 2: For each epoch compute the individual privacy loss of the query following Thm 4 of [[PPA-DP]]. There are three cases | ||
| * Case 1: If the epoch has no relevant impressions the privacy loss is 0. | ||
| * Case 2: If the window of epochs contains only a single epoch, the `individual_sensitivity` is the L1-norm of attribution function | ||
| applied to only the impressions in this epoch. The privacy loss deducted from the epoch's budget is | ||
| then `requested_epsilon * individual_sensitivity / query_global_sensitivity`. | ||
| * Case 3: If multiple epochs are considered, the privacy loss deducted from the epoch's budget is | ||
| `requested_epsilon * report_global_sensitivity / query_global_sensitivity` |
There was a problem hiding this comment.
I think that it would be easier for this to be integrated into the attribution logic than have it be standalone.
Ideally, that means that you would execute the attribution logic and return a value that this function uses. Right now, I think that ends up being a list of tuples, each containing (impression, value, week). The part that I find a little difficult to parse here is that you need to return (impression, value=0, week) for every week that contains an impression in order to make this theorem work. That's non-intuitive to me and requires a better explanation than I was able to find.
Update the algorithm for budget deduction to more closely follow the paper. Especially as it relates to using the sensitivity to compute the privacy loss.