Re: [attribution] Feedback on Attribution Level 1 draft

> That was the idea.  The thinking was that this was necessary for the
> leader to ensure that it can route new reports to the correct helper.
> How else would it manage?  Report submissions don't really identify
> the helper in a way that is clear enough to pick the right one.

In DAP, it's assumed that the task parameters have been distributed to all
protocol participants before reports start being aggregated, and the leader
and helper DAP URLs are among those parameters. Reports get uploaded to a
path that includes the task ID, which the leader would use to figure out
which helper is in play. Of course, now we might ask how the task gets
provisioned into the DAP aggregators. AL1 uses the task ID derivation from
taskprov (https://datatracker.ietf.org/doc/draft-ietf-ppm-dap-taskprov/),
but not the actual provisioning mechanism, so it follows that someone is
responsible for provisioning the task into aggregators before
`measureConversion` gets called by a given site

Actually, now that I'm looking at "7.1.3. Report Encryption For DAP" again,
I notice that the taskConfig structure described there has an empty
task_info. What's the lifetime of the resulting DAP task?

Tim

On Tue, May 26, 2026 at 5:24 PM Martin Thomson <mt@mozilla.com> wrote:

> On Wed, May 27, 2026 at 4:22 AM Tim Geoghegan <timgeog+ietf@gmail.com>
> wrote:
> > re: Discovering aggregation services
> >
> > I'm comfortable with your explanation. I agree that the mechanics and
> politics of aggregation service choice and availability are beyond the
> scope of this specification. One thing to clarify: it sounds like it's
> impossible for a conversion site to use an aggregation service that the
> browser doesn't already support? There's no way for it to dynamically,
> programmatically BYO an aggregation service? That seems fine to me, just
> want to make sure I understand how this works.
>
> Not really.  At least in the short term.  We'll be doing manual
> vetting on the browser side for the foreseeable future, but I'm sure
> we'll be open to any ideas people have to smooth this process.
>
> > re: Fetching aggregator config
> [...]
> > Right now, I think you'd have to require the leader to add path
> components to their DAP API URL to distinguish between helpers, which would
> work, but is kind of awkward.
>
> That was the idea.  The thinking was that this was necessary for the
> leader to ensure that it can route new reports to the correct helper.
> How else would it manage?  Report submissions don't really identify
> the helper in a way that is clear enough to pick the right one.
>
> If I'm wrong, maybe there's a clever hack:
> https://example.com/leader#helperA is a distinct URL that won't be
> distinguishable from https://example.com/leader#helperB at the server
> end.
>
> > re: `time_precision` = 5
> >
> > It sounds like the collector chosen batch mode may ignore report
> timestamps, which is fine. The remaining consideration is timestamp as a
> fingerprinting signal. DAP clients are required to round timestamps down to
> the task time precision, meaning that this value would be a 5 second
> resolution signal of when someone somewhere used the attribution API at
> all. I think a decision needs to be made at the AL1 layer whether that's a
> dangerous signal, in which case you would set the time precision higher
> until you feel that an acceptable amount of information leaks.
>
> Passing the precise time is fine.  At least for our privacy model.  We
> assume that anything a site knows is also communicated to both
> aggregators.  The time that a conversion occurs is, at least for these
> actors, public information.
>
> Thanks again Tim.  I appreciate the effort, and the excellent
> questions and feedback.
>