- From: Martin Thomson <mt@mozilla.com>
- Date: Wed, 27 May 2026 10:24:18 +1000
- To: Tim Geoghegan <timgeog+ietf@gmail.com>
- Cc: public-patwg@w3.org
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.
Received on Wednesday, 27 May 2026 00:24:35 UTC