Agenda Request - IPA Status Update

[eriktaubeneck]

Agenda+: IPA Status Update

@martinthomson, @benjaminsavage, @bmcase, Daniel Masny, and myself are planning to publish an update on IPA in the coming week. We'd like to set aside some time at the next meeting to share our progress.

Links

This is a follow up to our initial proposal. I will add a link to the update here once it's published.

[AramZS]

@eriktaubeneck Can do! How much time do you need to present? And I'd think at least 30m for Q&A.

[eriktaubeneck]

I think 90 min (if we have room for it) will suffice (including 30 min of that for Q&A.) Thanks!

[eriktaubeneck]

Here's a link to our latest draft of the protocol. We'll present an overview during the session (though likely won't get into all the technical details.) We will be prepared to answer questions about any part of the proposal, and also encourage people to open issues directly on the newly created IPA Draft repo.

[eriktaubeneck]

Updated links (original comment included the wrong repo): latest draft and IPA Draft repo

[alexWhitworth]

@eriktaubeneck as I understand the latest draft, the suggested helper party network consists of an advertiser, an ad platform, and a trusted 3P. Given the expectation of a trusted 3rd party to ensure the MPC is not compromised, (1) how is it suggested such a 3P is chosen, and (2) is there a need for the MPC at all (vs a less technically sophisticated protocol such as a "data clean room")?

[benjaminsavage]

Hi @alexWhitworth - I think you've misunderstood the proposal. That is not what the "helper party network" refers to.

It refers to a group of three distinct companies, each of whom operate a server which would run an MPC protocol that conformed to the specification.

These entities are minimally trusted. That is, they are never entrusted with raw user data. They only ever see "secret shared" data, which cannot possibly be converted back to raw user-data without collusion between the helpers. As such, the only thing we need to trust about these helpers is that there is AT MOST one malicious one. So long as there is at most one malicious helper, it is not possible for user privacy to be violated.

As for how these three entities would be chosen, it would be up to the browser or mobile-OS vendor to select a group of companies that they trust to not intentionally collude amongst one another to violate user privacy.

[alexWhitworth]

@benjaminsavage thanks. Yes, I understood everything in your comment/proposal except whom the 3 parties are, particularly as it relates to a real-world use case. I understand that the MPC allows malicious actors in <= 1/3 of the parties.

Looking forward to discussing this in this afternoon's meeting.

[eriktaubeneck]

Thanks for the question @alexWhitworth. The technical proposal is intentionally abstract about the helper parties networks; for the protocol, we have to assume that such a group of parties that will be trusted by browser vendors to have this non-collusion property will exist.

What you are getting at is actually more of a policy question (and less of a technical one.) Who will run these? My personal opinion is that we'll likely see a small handful of such networks emerge, and my hope is that some of them will be trusted to be non-colluding. I imagine these will consist of entities like the Internet Security Research Group (ISRG) who is working on a service similar to this, DivviUp.

As for publishers and advertisers participating in the helper party networks: this seems less likely. In the past, I've heard the view that we should assume in our threat model that publishers and advertisers are colluding. So it's unlikely this becomes advertiser + publisher + trusted 3rd party, but rather networks of semi-trusted 3rd parties.

As for the need for MPC (vs a "data clean room".) This is more relevant to the threat model discussion. which there is a draft in the Docs and Reports repo. But in general, even if we have a helper party network made up of 3 (more abstractly, more than 1) parties all very much like the ISRG, the goal is to not have to trust any single party. In terms of the threat model, there shouldn't be any single entity who could collude with a publisher, advertiser, or report collector, and reveal the data, hence the need for an MPC.

[benjaminsavage]

Today at the PAT-CG meeting Chris Wood mentioned that Cloudflare would also be interested in operating open-source MPC protocols like DivviUp and potentially IPA. So that's another specific answer to your question @alexWhitworth =).

[martinthomson]

cc @chris-wood who can probably qualify that more precisely.

[alextcone]

It’s hard for me to believe that any public cloud provider would turn down digital advertising compute. In fact I would assume all of them are salivating watching this work and the related work at IETF. I think the question is, do we intend to look to the cloud providers themselves for being responsible and responsive for issues with their implementation? The Divviup example shows us that at least some browsers would trust a service provider built on top of the public cloud provider. I presume this is in part because Mozilla is on the board of ISRG. It’s noteworthy that OVHCloud and Amazon are also on the board. Cisco as well. Ultimately, I realize it’s up to user agents to decide who to encrypt toward, but I cannot imagine there are cloud companies or honestly anyone else who will say “not interested.”

Maybe a better way for me to frame it is, we can assume a lot of folks are going to raise their hands to run this system and no matter how you slice it the public clouds will make new compute money, so what criteria are important for filtering through all the interest?

[eriktaubeneck]

Folks, I opened What parties will participate in helper party networks? in the private-measurement repo to continue this conversation. I did my best to summarize points above, but please feel free to add more detail and continue the conversation there.