Re: [private-measurement] Interoperable Private Attribution (IPA) (#9)

A few thoughts:

1. We might not have to select the "trigger value" in the browser. It might be possible to select it later, server-side. This would include some amount of work to split it up into secret shares and compute a ZKP server-side. 
2. I suspect the bound on trigger values will be scoped to the Query. So if you run 10 different queries, you could provide a different bound for each. This should help with your problem #2. You could run one query which is just counting app-installs, and each trigger event would just have a trigger value of 1. You could run a separate query which is totalling sales, and use a much higher bound.
3. I do not think we will have to resort to hacks like splitting an event up into multiple events. However, there *will* need to be a (per-query specified) total limit, of the total amount a single user can contribute to the value. This is a separate limit in addition to the per trigger-event limit on the trigger value. This is necessary to provide a differential privacy guarantee. So unfortunately, if one user makes a ton of huge purchases, their total contribution will be capped. Again - as this is a per query param, you can find your own optimal tradeoff between a high value (less capping, but more DP noise added), or a low value (more capping, but less DP noise added).

-- 
GitHub Notification of comment by benjaminsavage
Please view or discuss this issue at https://github.com/patcg/private-measurement/issues/9#issuecomment-1181811739 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 12 July 2022 14:12:24 UTC