Charlie Harrison

> Thanks for tagging me. I agree with @domfarolino that we should probably land on something coherent with what FedCM is doing. > > I went back to look at...

In our case I think a CORS mode fetch with the request's origin set to the `reporting endpoint` (what this PR does) makes the most sense. While the request isn't...

1. A [network request for source registration](https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources) is made to the reporting origin, on site A. The reporting origin uses response headers to register a source. 2. A [network request...

> Can't a random site just click a link and then trigger a request to the reporting origin? I'll admit I don't have a lot of context here so I...

> @letitz's analysis makes sense to me. One more question - are the requests expected to be CORS-safe requests? Discussed offline, but I don't think these are quite CORS-safe because...

I think this really hinges on whether we need to add random noise to report delays, since the existing API does not have any noise except to stagger queued reports...

Good point. I thought about this with @johnivdel and I think we concluded that reporting a time that omits browser downtime (and associated randomized report delays at startup) is fine...

Though I suppose in some sense you will be able to learn this with any implementation of the event level API to some extent, especially if you configure just a...

Yes I think the natural way to solve this is to introduce some noise to startup that hides browser-uptime a bit more. Right now we add uniform noise to simulate...

It seems reasonable to me, but one problem with wider delays is that it has a chance of perpetually delaying conversions from users that use the browser for very short...