attribution-reporting-api icon indicating copy to clipboard operation
attribution-reporting-api copied to clipboard

Noised sources with no reports are handled differently from noised ones with reports

Open apasel422 opened this issue 9 months ago • 3 comments

In step 2 of "trigger event-level attribution" we return early with a trigger-event-noise verbose debug report when the attributed source has a non-zero-report randomized response, but we do not return early when it has zero-report randomized response, which ends up causing subsequent early-return-verbose-debug-reports to be favored over the trigger-event-noise one. For example, step 5 can end up producing a trigger-event-no-matching-configurations verbose debug report, even though attribution would still have failed even if there had been a matching configuration, due to the handling of noise in step 22.

This seems inconsistent. Is there a reason the non-zero-report one always gets trigger-event-noise but the zero-report one only gets that verbose debug report some of the time? It seems like a strange, and perhaps unintentional, mix of non-noised behavior with noised behavior.

Similarly, verbose debug reports issued before this algorithm is called (e.g. trigger-no-matching-filter-data) are also favored over the one specifically for noise.

apasel422 avatar May 08 '24 12:05 apasel422