The explainer on Aggregated Reporting talks about some answers on reporting:

• The Authenticating Inputs section of that doc discusses how to only accept reports for aggregation where the server has stamped parts of them as being reliable. That explainer talks about an auth tokens coming from each of the ad click and ad conversion, but for TURTLEDOVE presumably we would want a token each from the publisher side and the advertiser side of the page.

• This issue on Poisoning Inputs is about the sort of mechanism you would need to ensure that the pre-aggregation cost-per-impression is in the expected range.

TURTLEDOVE could provide a similar re-use of the blind-signature cryptographic tokens to give an ad network a way to be sure the ad request genuinely came from someone they had added to the interest group.

Browsers also choose what it's possible for extensions to do, which could offer protection against some attacks. But if you're worried about behavior by botnets of modified browsers, this won't be of much use.

I am not sure that I understand how things would work here.
Does that mean that the advertiser would have to authenticate the bids (among other things) for all the impressions he made (to then only receive an aggregated report)?
How would that work? What data would be available to each side for providing the Auth token?

Putting any attack aside, a bug of any form could happen and induce a billing discrepancy between the advertiser and the publisher.
How would such conflict be resolved since there is no source of truth?
Could you give more details about how you envision the balance clearing process when neither of the two actors involved has a full and accurate picture?

If you're thinking about bugs in the aggregation infrastructure, then the natural way to gain confidence in it is to send known data through the aggregation pipeline, and verify that you get the right aggregates out the other side.

If you're thinking about bugs in the JS code that runs in the browser and creates individual events to be aggregated over (saying e.g. "advertiser A should pay $x" and "publisher P should receive $y"), this is the sort of code that can be audited, and indeed can be seen by everyone — basically what you were complaining about in #32, I think!

The input to that in-browser JS is signals generated on a server, and those signals can be individually logged and reconciled just like in today's world.

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Private Aggregation proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.