Account for the number of entropy bits exposed in reportingdomain

[ehsan]

Let's say on the impression side we have a link like:

<a href="..." reportingdomain="https://uniqueid.adtech.example/" ...>...</a>

https://github.com/csharrison/conversion-measurement-api#conversion-reports mentions the conversion report will be sent to:

https://reportingdomain/.well-known/register-conversion?impression-data=&conversion-data=&last-clicked=

The number of unique bits sent alongside with this request seems more than what's mentioned there, since uniqueid may be a string that is unique e.g. per user (like a hash of their email address) or per their device (like a fingerprint).

This could be solved for example by submitting the conversion report to:

https://reportingrootdomain/.well-known/register-conversion?impression-data=&conversion-data=&last-clicked=

Where reportingrootdomain is the eTLD+1 of reportingdomain.

[ehsan]

It occurred to me that the work-around I suggested above may not be sufficient for removing all possible entropy here. Here is another possible example:

https://ad-tech.example is the impression side, where ad-tech.example has a first-party relationship with the user and e.g. knows User X is logged in right now. A unique domain is registered for each user account in the system and the reportingdomain attribute is set to that unique domain for ads appearing on https://ad-tech.example when the user is logged in. This would allow the reporting domain to learn about the identity of the user by looking at the Host header.

[csharrison]

The input reporting domain at impression time is defined as an eTLD+1, so you shouldn't be able to do tricks with unique sub-domains (see https://github.com/csharrison/conversion-measurement-api#impression-declaration). We should always send the report to the root.

If folks are registering unique full domains per user at impression time, they will hit a pretty difficult problem: matching users to those domains at conversion time in the advertiser's context. We only send reports to the reporting domain if they are declared in the conversion registration .well-known URL. In order to learn the unique reporting domain, the advertiser would need to cycle through every possible domain which is easily thwarted (see this section https://github.com/csharrison/conversion-measurement-api#limits-on-the-number-of-conversion-pixels).