- From: Charlie Harrison via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 May 2022 21:22:21 +0000
- To: public-patcg@w3.org
> [Administrative side note, I opened a https://github.com/patcg-individual-drafts/admin/issues/1 to get a repo specifically for IPA so we can have issues to dedicated topics, and even put together pull requests for docs outline more details in these areas as they emerge.] Thanks, yeah. This one issue is getting very cumbersome haha. > In the first scenario, it should be possible for the 1P to prevent a 3P from getting actual events by not sending them or installing their "pixel" code. It's worth thinking through this scenario to see if we could detect / tolerate this. As far as I understand things, it is notoriously difficult for 1Ps to make configuration changes on their sites, so if we are relying on that to deter cheaters it's not ideal. > In the first scenario, it should be possible for the 1P to prevent a 3P from getting actual events by not sending them or installing their "pixel" code. Hm, this made me look back at the IPA doc to see how privacy budgeting is done. For a given report in the MPC system, how do we know the site it is associated with for purposes of budget? The issue I am hoping we can avoid is something like a re-randomization attack where a 3P gets _real_ events for advertiser A but can somehow use the match key to steal budget from advertiser B while having the report look new. I think we need to make sure the budget keys are not tamperable basically. I think I agree with you about the high entropy protecting us a great deal from the "guessing" attack. If we can show that's the worst an adversary can do I might be comfortable with it. -- GitHub Notification of comment by csharrison Please view or discuss this issue at https://github.com/patcg/private-measurement/issues/9#issuecomment-1120016874 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 6 May 2022 21:22:23 UTC