Consider allowing JSON integers in some places where strings are required today

[apasel422]

Due to the implementation-specific nature of JSON integers, wherever source or trigger registration requires an integral value today, we require the value to be encoded in base 10 and placed in a string¹. This is tedious for cases where the value effectively always fits in a JSON integer, both on the reporting-origin side, which must encode, and on the browser side, which must decode. The relevant fields are:

• Attribution-Reporting-Register-Source
  • source_event_id and debug_key: unsigned, deliberately chosen to allow 64 bits of source-side data to be included in the report
  • priority: signed, deliberately chosen to allow "drop-in" use of 64-bit timestamps as the value
  • event_report_window and aggregatable_report_window: unsigned, representing an offset in seconds, but constrained to the range [3600, 2592000] (min report window, max source expiry)
  • expiry: unsigned, representing an offset in seconds, but constrained to the range [86400, 2592000] (valid source expiry range)
• Attribution-Reporting-Register-Trigger
  • debug_key: unsigned, deliberately chosen to allow 64 bits of trigger-side data to be included in the report
  • deduplication_key: unsigned, no particular reason for 64-bit values, but no obvious reason to restrict them
  • priority: signed, deliberately chosen to allow "drop-in" use of 64-bit timestamps as the value
  • trigger_data: unsigned, subject to a modulus operation that constrains the value according to a vendor-determined limit according to the attributed source's type (navigation sources, event sources). For Chromium, this is currently [0, 7] and [0, 2], respectively.
  • aggregatable_values: Somewhat inconsistently, already the only field that is required to contain JSON integers rather than strings. Required to be in the range [1, 65536].

The flexible event-level proposal indicates that the modulus operation may be removed entirely and that the values may be specification-limited to the range [0, 31] in the future. That proposal also introduces a number of other integral fields whose valid range indicates that they could be integers, rather than strings. On the source side: trigger_specs.event_report_windows.end_times, trigger_specs.summary_buckets, and max_event_level_reports. On the trigger side: value².

Given these valid ranges, we could extend the JSON schemas to allow integers in some contexts where strings are required today. In particular, the source expiry, aggregatable_report_window, and event_level_report_window fields, and, if the flexible event-level proposal is accepted, the trigger_data field on both the source side and trigger side.

Footnotes

1. For source aggregation_keys and trigger key_piece, the values are 128-bit unsigned integers encoded in base 16 and placed in a string. ↩

2. Given that the value_sum summary operator performs integer arithmetic on trigger values, some kind of range will need to be defined there and applied to the source-side summary_buckets as well. ↩