Consider hour-level expiry within a one-day conversion

[logicad]

Currently, Attribution-Reporting-Register-Source's expiry is rounded to the nearest day.

On the other hand, in our system (and business), it is important to distinguish conversions that arise within 24 hours after a click at the hourly level.

Thus, we want the nearest-hour round of the expiry when its value is within 24 hours after the click.

Of course, it may not be appropriate from the viewpoint of the user's privacy.

We would appreciate it if anyone could give any comments on this idea.

[csharrison]

Hey @logicad , thanks for filing this issue. I don't think I fully follow what you are asking for though. I think it would help to provide an example of what cases you would set the expiry to <24h and why. What is the shape of the resulting data that you want to obtain?

There might be mechanisms in the API to help you achieve your goals without changing the expiry rounding (which does indeed have some privacy benefit).

[logicad]

Hi @csharrison, thank you for your comments. The reasons of setting the expiry to <24h is to count only last click or direct conversions from our ad click. The longer the expiry, the more likely the conversion is not our last click conversion, for example, from search engines or other ad-tech ad clicks.

Currently, about 3% of our advertisers are set up to count only one hour from the ad click as a conversion.

[csharrison]

Thanks @logicad this makes sense to me. The concern we had when the expiry is hourly is the following attack:

• User lands on site A
• site A logs 24 impressions, with expiries at hour 24, 23, ... , 2, 1 from the impression.
• User converts at time T, which is attributed to the impression with the smallest expiration that hasn't expired yet
• This lets the site learn the hour the user converted

This attack is somewhat convoluted, and it is mitigated if we:

• Allowing this only when the expiry < 24 hours (limits the damage to differentiating 24 different impressions)
• Allowing this only for clicks (and not views), which makes it much more difficult to have a lot of pending impressions.

But still there is a marginal privacy regression if we allow this. A few questions: Can you verify that you only need these for clicks? Would it be acceptable to have coarser data than hourly, e.g. 3-hour granularity, 12-hour, etc? This further mitigates the privacy leak.

Note that there are techniques to do this at the filtering layer which don’t have this negative privacy property (because failing a filter drops the trigger rather than picking another source to attribute to), but doing this with filters is fairly complicated as they were designed for binary matching vs. numerical comparison.

[logicad]

@csharrison Thank you for your response.

I will answer your questions. We would like to need not only for clicks but also for views. But if there is a privacy protection issue, we can accept to apply only for clicks. Yes, it would be acceptable to have coarser data than hourly.

[csharrison]

Hey @logicad we are thinking of changing the event-report-window minimum to be 1 hour. I think that should fix this issue, is that right?

https://github.com/WICG/attribution-reporting-api/pull/865

[logicad]

Hi @csharrison, Yes, changing the event-report-window minimum to be 1 hour solves this issue.