Support filtering: Add a (cleartext) per-report context ID to reports

[csharrison]

The privacy model of PAM assumes that the server receiving a report can associate it 1:1 with the context that created it. This is due to the fact that reports are sent unconditionally and deterministically when the API is invoked.

Given that this is assumed to be known by a potential adversary already, I think there is value in making this relationship explicit. API invocation should allow the caller to specify some context_id, which could be embedded in the cleartext of the report when it is sent out.

This ID is useful for a number of different use-cases:

• Filtering spammy aggregates: an offline process can mark various impression / conversion events as spammy or fraudulent after they occur, based on the context that created the event. It would be useful to have a hook into this ID within a report, so that we could potentially support filtering out reports matching certain spammy IDs
• Context IDs may be useful if we support post-hoc grouping of reports based on their identifier (will file a follow-up issue on this)
• Context IDs make the API more understandable. Servers processing reports can (in theory) know which of their API invocations actually successfully led to reports being sent out and when (useful for debugging).

Let me know what you think, or if I’ve misunderstood the PAM privacy model in some way. This is the direction we are thinking of going in ARA in WICG/attribution-reporting-api#974, which matches the "unconditional report" model of PAM and introduces an ID for filtering along the way.

[winstrom]

This seems reasonable to me. The timestamp of the event in principle gives this information so I don't believe this contributes extra information for cross site linking. And I appreciate any debugging help in this type of system.