Default and limit summary_buckets based on max_event_level_reports

[apasel422]

The max_event_level_reports value (whether explicit or defaulted based on source type) restricts the maximum number of reports that can be produced from a single source. Therefore, it is misleading to have more than that number of summary_buckets, since bucket increments will stop once reaching max_event_level_reports.

Rejecting sources with inconsistent values in these fields will help prevent developer errors, and both the rejection and defaulting based on max_event_level_reports bounds the storage space needed per trigger_spec for the summary_buckets field to 20, which is the max settable value for max_event_level_reports.

This is a revival of #1021, which has more discussion.

[giladbarkan-github]

Set to max_event_level_reports + 1; otherwise, the expected last bucket will use max int rather than the provided bucket.

[apasel422]

Set to max_event_level_reports + 1; otherwise, the expected last bucket will use max int rather than the provided bucket.

To clarify, given the following source registration:

{
  "max_event_level_reports": 3,
  "trigger_specs": [{"trigger_data": [0]}]
}

and the following trigger registrations:

{"trigger_data": "0"}
{"trigger_data": "0"}
{"trigger_data": "0"}

are you saying that the PR as written would yield the reports

{"summary_bucket": [1, 1]}
{"summary_bucket": [2, 2]}
{"summary_bucket": [3, MAX_UINT32]}

instead of

{"summary_bucket": [1, 1]}
{"summary_bucket": [2, 2]}
{"summary_bucket": [3, 3]}

?

I'd like to see https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#reporting-trigger-counts updated to show what happens on the eleventh trigger.

[giladbarkan-github]

{"summary_bucket": [3, 3]} would correspond with the explainer since it's an infinite list. My comment was about the truncation since without the last+1 bucket, the value of the trigger summary bucket would be unexpected.

[apasel422]

{"summary_bucket": [3, 3]} would correspond with the explainer since it's an infinite list. My comment was about the truncation since without the last+1 bucket, the value of the trigger summary bucket would be unexpected.

There's no truncation here per se. There's a default if the field is omitted, and there's an error if the field is too long.

Could you take a look at https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#reporting-trigger-value-buckets and see if you agree with the behavior there?

[giladbarkan-github]

{"summary_bucket": [3, 3]} would correspond with the explainer since it's an infinite list. My comment was about the truncation since without the last+1 bucket, the value of the trigger summary bucket would be unexpected.

There's no truncation here per se. There's a default if the field is omitted, and there's an error if the field is too long.

Could you take a look at https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#reporting-trigger-value-buckets and see if you agree with the behavior there?

What would be the expected trigger_summary_bucket value in the report if summary_buckets is not provided in the registration and max reports is 1? How would that value correspond with "If omitted, then represents a trivial mapping [1, 2, ... , MAX_UINT32]"?

[giladbarkan-github]

Do we need to state that the report corresponding with max reports always has MAX_INT in its trigger_summary_bucket value?

[apasel422]

How would that value correspond with "If omitted, then represents a trivial mapping [1, 2, ... , MAX_UINT32]"?

This PR replaces that statement.

[giladbarkan-github]

How would that value correspond with "If omitted, then represents a trivial mapping [1, 2, ... , MAX_UINT32]"?

This PR replaces that statement.

Ah, gotcha, thanks!

[apasel422]

Or maybe amend the trivial mapping [1, 2, ... , MAX_UINT32]" to trivial mapping [1, 2, ..., max reports, MAX_UINT32]"?

I think we may be confusing the JSON registration syntax with the equivalent inclusive ranges. Given JSON [a, b, c] the inclusive ranges are [ [0, a - 1], [a, b - 1], [b, c - 1], [c, MAX_UINT32] ].

[giladbarkan-github]

Why is it OK for summary bucket list to be shorter than max reports? Which summary bucket do the extra reports get?

[apasel422]

Why is it OK for summary bucket list to be shorter than max reports? Which summary bucket do the extra reports get?

There are no extra reports: max_event_level_reports restricts the total number of reports across all trigger specs for the source.