Consider adding a nonce to attribution reports

[johnivdel]

As described in https://privacycg.github.io/private-click-measurement/#receving-reports,

We may have to add a nonce to the HTTP POST request to prohibit double counting in cases where the user agent decides to retry the request.

There are potentially many edge cases that can cause the reporting endpoint and the browser to have a different view of what happened to a request.

For example, the report request made it to the reporting endpoint server but there was a transient network issue before response headers were received by the client. Without adding a nonce, any retry logic has the potential to introduce counting issues.

This would be beneficial for both aggregate and event-level reports.

[johnivdel]

A few concerns/suggestions were brought up in the 10/4 meeting on this which I would like to document on this issue:

@johnwilander expressed some concern that browsers retrying reports would allow sites to receive multiple pings from users, allowing the server to learn additional information about whether a user is online. It's possible this could be addressed by limiting the number of retries done by the client to some small amount (e.g. 1-3) and adding some randomness to the retry times.

There were a number alternatives to using a nonce suggested.

One idea was to use the "report_time" of the report to indicate unique-ness. Assuming there is sufficient granularity in the timestamp, this could effectively be unique per report. This field was requested for other reasons on #47.

This gets complicated by the reporting window behavior in Attribution Reporting, where multiple reports for the same window share the exact same report time. While this still might be sufficient in practice due to the coarseness of conversion side information, it makes detecting double counting more complicated as reporting endpoints need to account for the multiple conversion per source behavior.

Another idea was to use an auth token as a unique per-report value. This suffers from the same issue of conflating two use-cases. For example, a token authenticating the source is not sufficient in Attribution Reporting due to the one-to-many relationship between sources and reports.

A conversion side authentication token would fix this issue, but there are still outstanding issues with making per-event trigger tokens work, see #111.

Having a dedicated field avoids these interactions/dependencies, but is introduces a new concept to reports and grows the report JSON schema.