Spec: Aggregation coordinator choice #106
Conversation
Adds a mechanism for choosing between multiple aggregation coordinators. See also the explainer update: #101
|
@linnan-github, could you PTAL? Thanks! cc @yoavweiss |
spec.bs
Outdated
| : <dfn>context ID</dfn> | ||
| :: A [=string=] or null | ||
| : <dfn>queued</dfn> | ||
| :: A [=boolean=] | ||
|
|
||
| </dl> | ||
|
|
||
| <h3 dfn-type=dfn>Aggregation coordinator</h3> | ||
| An aggregation coordinator is an [=origin=] that the [=allowed aggregation |
There was a problem hiding this comment.
Shall we use suitable origin to align with ARA?
https://wicg.github.io/attribution-reporting-api/#aggregation-coordinator
There was a problem hiding this comment.
I added an issue here -- we don't have the 'suitable' concept in PAA yet. It might make sense to switch over, but I think currently most of the logic does not assume that the scheme is either http or https.
spec.bs
Outdated
| : <dfn>context ID</dfn> | ||
| :: A [=string=] or null | ||
| : <dfn>queued</dfn> | ||
| :: A [=boolean=] | ||
|
|
||
| </dl> | ||
|
|
||
| <h3 dfn-type=dfn>Aggregation coordinator</h3> | ||
| An aggregation coordinator is an [=origin=] that the [=allowed aggregation |
There was a problem hiding this comment.
I added an issue here -- we don't have the 'suitable' concept in PAA yet. It might make sense to switch over, but I think currently most of the logic does not assume that the scheme is either http or https.
|
@qingxinwu @xyaoinum could you PTAL too? (Or reassign) Thanks! |
|
I'll be able to take a look later tomorrow (Friday), if that's not too late. |
|
Tomorrow works! Thanks both |
Adds a new aggregation_coordinator_origin field to the Private Aggregation layer. This field is validated and then sent on to the aggregation_service layer. This change is not web visible as the integrations with Shared Storage and Protected Audience will be added in separate cls. See the related spec change: patcg-individual-drafts/private-aggregation-api#106 Note that this also modifies behavior of the database to only skip reports that do not deserialize instead of skipping all reports if there is any that do not deserialize. This may change behavior in case of database corruption. Bug: 1481254 Change-Id: Ie90eafc208f94ffd98ad95642b8f8c9b0af85fac Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4885966 Reviewed-by: Yao Xiao <yaoxia@chromium.org> Reviewed-by: Russ Hamilton <behamilton@google.com> Commit-Queue: Alex Turner <alexmt@chromium.org> Reviewed-by: Nan Lin <linnan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212827}
|
Hmm didn't find a place to approve, maybe I cannot. But LGTM |
|
Thanks! |
SHA: 55019b5 Reason: push, by alexmturner Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Adds a mechanism for choosing between multiple aggregation coordinators. See also the explainer update:
#101.
To simplify this spec change, the Protected Audience integration's get batching scope steps are modified to be lazy.
Preview | Diff