IPA Biweekly Meeting Agenda Request - Chrome Standards Position and open concerns

[bmcase]

Agenda+: Standards Position of the Chrome Privacy Sandbox Measurement Team

I propose we give some time to discuss the recent issue on the Standards Position of the Chrome Privacy Sandbox Measurement Team . We could start by letting the Chrome team add any additional color and answer any questions before getting into discussing on a select few of the open concern bullet points (I propose we focus on trigger side breakdowns, match keys without JavaScript (if this needs discussion), delegated report collectors).

@csharrison let me know if this sound good to you or if you want to change it up at all

Time

Overview and questions: 15 min

Select bullet points to discuss (remaining time, 25min):

IPA’s server-side infrastructure will need to process multiple orders of magnitude more data than ARA’s, because it moves the on-device join into the server. We need to be confident that this is feasible and cost-effective for all critical use-cases. See patcg/private-measurement#21 on the private-measurement repo for the general scale issue for off-device attribution.

Since last meeting we talked mostly about scale and I don't think there are any updates in this area, I propose we revisit scaling proposals in a later biweekly call.

IPA has been designed to provide only simple aggregates keyed by impression-side information, which doesn’t address fundamental ecosystem use-cases including model training or reporting by conversion type #55. We will need to ensure that IPA can provide a rich enough set of outputs such that these use-cases and others can be achieved. This may also require investigating alternative privacy mechanisms.

I propose we discuss this issue on trigger side breakdowns and what sort of circuit we would want to compute in the MPC using trigger breakdownkeys. As for alternative privacy mechanisms discussed in #60, it looks like the next step from the comments thread is to bring this to the broader PATCG for discussion.

#39: IPA’s pervasive sharing of “match keys” means match key providers are forced to share proprietary user data with arbitrary other parties on the web.
#42: IPA allows for arbitrary linking to off-device and off-web events, as long as they can be annotated with a match key. This potential abuse vector is hard to reason about and may need extra mitigations before we’re confident it’s safe. See also #57 which identifies a privacy attack based on this capability. Potential fixes which remove the notion of a match key provider reduce the potential utility of IPA (e.g. to support attribution across platforms).

We may have already covered in the earlier part of the meeting but can revisit if there is more to discuss.

#25: IPA currently only specifies a Javascript API, which we don’t think will be tenable for real-world adoption where ad measurement is often at the HTTP layer.

This is outside my area, so will let others decide if they want to discuss anything in the meeting.

If sites participating in IPA want to delegate to one (or many) third parties to do their measurement for them, they need an explicit mechanism to advertise to browsers/helper party networks about this delegation. This mechanism is not currently well-defined in the IPA proposal (although a strawman is discussed in #6). Our experience with deploying ARA leads us to believe that this mechanism will be a source for issues unless carefully crafted.

Would be great if we have time to discuss this; I've been thinking of flushing this out more recently. It would be great to hear from the experience of deploying ARA what some of the challenges may be.

Issue Link

#59

[csharrison]

I would be happy to discuss. When is the next meeting? Is it today or next week? The issue says "second and fourth wednesday", but the last meeting was two weeks ago.

[bmcase]

@csharrison I was thinking it was today but it is next week. I missed that it was "second and fourth wednesday" and not truly biweekly.

[csharrison]

OK great. That gives me more time to prepare 😆

[bmcase]

closing this agenda issue as we discussed in our 4/12 meeting