Attribution Scopes - New Explainer #1282
Conversation
akashnadan
requested review from
vikassahu29,
apasel422,
johnivdel and
linnan-github
Update chromium parameters for attribution scope proposal
correcting spelling of rate limit Co-authored-by: Andrew Paseltiner <apaseltiner@google.com>
added missing word Co-authored-by: Andrew Paseltiner <apaseltiner@google.com>
Suggestions consisted of correcting spelling errors, formatting, and word choice. Co-authored-by: Andrew Paseltiner <apaseltiner@google.com>
update to deletion logic wording
added an "Alternatives Considered" section to the explainer
Editing wording so max_event_states comment is clear
| "attribution_scopes": <list of strings>, | ||
|
|
||
| // Optional | ||
| // Represents the maximum number of event states that an API caller plans to use across all |
There was a problem hiding this comment.
This makes it seem like all subsequent sources together make up the restricted event states. Rather than "across all," we could say "in".
|
|
||
| If the trigger registration's `attribution_scopes` is empty, then all sources are considered for attribution. | ||
|
|
||
| Once an `attribution_scope_limit` is set, the last K values (where K = `attribution_scope_limit`) of `attribution_scopes` will be considered the final set of `attribution_scopes` values and any source with additional `attribution_scopes` values will be treated as if the attribution scopes were empty. |
There was a problem hiding this comment.
My understanding is that this is partitioned by attribution destination. This makes it sound like any source can affect the K for any other source (per reporting origin), rather than only sources that intersect destinations.
|
|
||
| Once an `attribution_scope_limit` is set, the last K values (where K = `attribution_scope_limit`) of `attribution_scopes` will be considered the final set of `attribution_scopes` values and any source with additional `attribution_scopes` values will be treated as if the attribution scopes were empty. | ||
|
|
||
| If a source registration is specified with a configuration that has a higher number of event states than the most recent `max_event_states` for the same reporting origin, then the source will be rejected and the registration will fail. Additionally, if the `max_event_states` field is changed in a future source registration, then all other previous pending source registrations with a different `max_event_states` will be ignored in subsequent attribution report generation flows, but will still count towards rate limits. |
There was a problem hiding this comment.
Doesn't this whole paragraph only apply to sources that specify attribution scope limit (AKA an "attribution-scope source")?
|
|
||
| ### Deletion logic | ||
|
|
||
| If the current trigger is attributed to a source, then all other eligible sources considered for attribution (across all `attribution_scopes`) will be deleted. |
There was a problem hiding this comment.
Are sources that have no attribution scope limit specified also deleted?
| } | ||
| ``` | ||
|
|
||
| The API automatically performs attribution between any sources that have `attribution_scopes` that are not disjoint with the trigger `attribution_scopes`. Any sources that do not have an `attribution_scopes` that matches at least one of the trigger registration `attribution_scopes` are deleted (assuming there is a source that gets attributed and a report is generated; if no report is generated then no sources are deleted). In this example, the API caller would receive an attribution report attributing the trigger registration to advertiser1’s second source registration. |
There was a problem hiding this comment.
"...if no report is generated then no sources are deleted..." is this correct? Or is it enough that top-level filters match?
Addressing feedback comments from #1282
|
|
||
| ### Additional Privacy Limits | ||
|
|
||
| It is possible for an adversary to register multiple navigation sources during source registration, and use these multiple sources, each with a different attribution scopes value, to gain additional information about a user based on which attribution scope is chosen. To prevent this abuse the number of unique attribution scope sets per reporting origin per navigation needs to be limited. |
There was a problem hiding this comment.
To prevent this abuse the number of unique attribution scope sets per reporting origin per navigation needs to be limited.
Could an attacker register multiple origins to avoid the limit?
| <br> | ||
| The current attribution logic in the Attribution Reporting API may not be ideal for use-cases where an API caller needs finer-grained control over the attribution granularity (e.g. campaign, product, conversion ID, etc.) before a source is chosen for attribution. Currently available features such as top-level filters are not sufficient for this use-case because they happen after a source has been selected (i.e. after destination matching), which results in either no attribution occurring or incorrect attribution depending on the top-level filters that are set. We can support this use-case by allowing registrations to specify predefined attribution scopes that will be considered for filtering *before* attributing a source, in order to more efficiently extract utility from the API. | ||
|
|
||
| ## Goals |
There was a problem hiding this comment.
Please outline privacy goals. Is the proposal designed to be privacy neutral?
| "attribution_scopes": <list of strings>, | ||
|
|
||
| // Optional | ||
| // Represents the maximum number of event states that an API caller plans to use across all |
There was a problem hiding this comment.
all subsequent --> does this entail state tracking forever?
There was a problem hiding this comment.
"plans to use" --> what are the consequences if this is wrong? Maybe rather than framing as "plans to" we should frame it as "will be allowed to use"
|
|
||
| The `attribution_scope_limit` value can be updated during source registration at any time. However, any pending sources (previously registered) that have been specified with an `attribution_scope_limit` less than the current source registration’s `attribution_scope_limit` will be deleted. | ||
|
|
||
| ### Deletion logic |
There was a problem hiding this comment.
How about the interaction with user-initiated deletion? How does that change the statefulness of the system?
|
|
||
| ### Impact on flexible event-level reporting | ||
|
|
||
| The use of `attribution_scopes` will have some impact on the amount of utility that can be extracted from the [Flexible Event-Level](https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md) reporting proposal. In order to preserve the current privacy levels, the information gain limit that is used to verify acceptable flexible event-level configurations will now include the `attribution_scope_limit` and `max_event_states` values as part of the calculation. In other words, the additional information gain from the `attribution_scope_limit` and `max_event_states` that are chosen will be subtracted from the flexible event-level information gain limit and then used to identify whether the flexible event-level configuration is within the current privacy levels. |
There was a problem hiding this comment.
It might warrant a bit of an explanation of why this is the case, since it isn't obvious. Additionally - can we include the formula here? Unless I know how the information gain is impacted, it is hard to judge whether the trade-off is good for any one use-case.
|
|
||
| Note that the `attribution_scope_limit` does not have any impact on the privacy mechanisms used in Aggregatable Reports. | ||
|
|
||
| ### Additional Privacy Limits |
There was a problem hiding this comment.
Why do we need this if the information gain is accounted for above?
Related to #1215
Draft Explainer for Attribution Scopes Proposal.
This proposal also helps to address feedback from #1229