#823: Early design review request: IPA

Visit on Github.

Opened Mar 3, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Interoperable Private Attribution (IPA).

IPA proposes a system that enables cross-site attribution. The idea is to provide businesses that use advertising with a way to measure how their advertising is performing without having to rely on tracking. To do this, IPA assigns users with an identifier - a match key - that cannot be used outside of a multi-party compute (MPC) system. The MPC system only executes a specific protocol that has been vetted to ensure that it only provides aggregated information.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): PATCG
  • The group where standardization of this work is intended to be done ("unknown" if not known): PATWG (not approved, draft charter)
  • Existing major pieces of multi-stakeholder review or discussion of this design: Records of some discussion can be found in the project repository and PATCG minutes.
  • Major unresolved issues with or opposition to this design: The explainer includes sections that describe a number of open issues. We are planning trials that should help answer some of these.
  • This work is being funded by: Meta and Mozilla.

You should also know that...

The security and privacy questionnaire covers two key challenges, that I will highlight again here:

  1. This proposal uses information - match keys - that might be used to perform cross-site tracking if the protections in the proposal were to fail. The API allows any web site to request and receive this information from user agents. The proposal includes a number of measures that are designed to protect this information.

  2. The aggregated information that is provided to sites is based on the use of match keys. The use of differential privacy ensures that there is some protection for the contribution of individual users. The design limits the rate at which sites gain this information, so while the amount of information each week has strict limits, over time this limit always increases without bound.

Any conclusions about the privacy properties of the API will depend on an assessment of the adequacy of these protections.

We'd prefer the TAG provide feedback as 🐛 open issues in our GitHub repo for each point of feedback. We're happy to engage with general feedback, commentary, and questions in this thread; we expect some feedback to be very broad in nature.

Discussions

2023-03-13

Minutes

Hadley: not written from the perspective of the user...

Dan: really good answers to the security & privacy questionnaire...

Dan: https://github.com/w3ctag/design-reviews/issues/724 we said "multiple approaches..." do we want a different thing on each browser?

Hadley: IPA is set up with a multi-party computation model - makes tracking someone against their will a lot harder. This differentiates this proposal... will be better for user?

Dan: also points back to the user PoV..

Peter: do any of these benefit the user or just better ways of doing what advertisers want to do?

Hadley: conditional level of validation that the person has been validated somewhere else...

Peter: ...trust tokens...

Hadley: yes but trust tokens are completely anonymous... IPA protocol is an aggregate report... measure performance of use of adverising... (Reading from the security and privacy questionnaire) a lot can be said about the relative virtues of advertising .. not all will say advertising is necessary ... however you can't do advertising without being able to measure it. Alternatives involve tracking or surveys & panels ... expensive & slow and too inefficient for general use.

Dan: this is what Apple also say that they do... They have not requested a review yet even ...

2023-06-12

Minutes

Hadley: long discussion... api changed

2023-07-03

Minutes

Amy: They've responded to our qs. Also some conversation and changes to the spec since it was reviewed in Tokyo. We should re-review. They have some open questions, so if we have the right expertise in the TAG we can offer advice, but otherwise we should probably wait for it to settle down

Amy: How does this fit with Attribution Reporting API? (It's the same problem?)

Dan: Any neutral opinion / summary on the three proposals?

Amy: Maybe Nick Doty / Sam Weiler?

Dan: i'll take the action to reach out to Sam Weiler & Nick Doty

2023-07-mos-eisley

Minutes

Tess: I think something along these lines is probably the right thing for aggregated reporting...

2024-02-12

Minutes

Tess: last time there had been a unified approach... do you think it's worth spending time reviewing IPA as it is right now? Should we ask the PATCG to circle back when that happens?

Martin: Right, we've had a number of conversations about iterations that remove a persistant identifier, which is generally an all round improvement. We might appreciate guidance on the abstract notion - is it a good idea to support this use case - I don't think anything further than that would be useful

Tess: I propose we close this nicely and ask that they file a new request when the new proposal is ready

Peter: so is this a good idea?

Tess: we know that advertisers want to measure effectiveness, and they'll do so in a bunch of ways that are indistinguishable from cross site tracking. Since we're cracking down on cross site tracking, we're also cracking down on anything that resemebles cross site tracking because we can't distinguish. It's a good thing that people are trying to move off technology that is indistinguishable from cross site tracking. I'm happy that the industry is collaborating on something that is reasonbly privacy preserving, and I want to encourage that. I'd rather see a convergent solution.

Martin: there are a bunch of nonobvious properties of a system like this. We talked about targeted advertising previously. All advertising is targeted to some extent. Also, being able to measure effectively creates the ability to better target your advertising, whether or not that comes with the ability to gain more information about people is orthogonal. Assuming you have some amount of information about people, the ability to measure the effect of advertising on people gives you the ability to realise which people will be more receptive to your message.

Peter: that's my concern. In general I'm against targeted advertising because it does what it does in a harmful way. I get the business case for wanting to measure the effectiveness. I don't want to add technology to the web to just enable a business case. But as long as we can come up with a way that doesn't cause harm - if it can't be abused, I can't oppose it. There is a fine line between effective commercial advertising and effective manipulation of peoples opinions. There's a lot of evidence that social networks in general have caused all sorts of harm this way.

Martin: we thought a lot about this. We concluded the harm minimisation aspects were significant enough to justify doing it, but only on the basis that the privacy tuning of the proposal was sufficiently good. Effectively making sure that the information made available to advertisers isn't good enough for them to do some of the more sophisticated stuff. We may not ever achieve that - really bad information is still pretty good for some people. Some really interesting equity questions that raises. With our primary tool being differential privacy, what are the tuning parameters we put on this? At oen end of the scale it's useless, and at the other end you've not moved the privacy needle at all.

Peter: when it comes to harm reduction, there are lots of existing mechanism used to track and identify people. If we give them a way to get the same effect without that level of invasiveness, but the amount of information they get they don't believe is as good they'll still do the harmful thing. We have to remove the ability to do the harmful thing, and if we can do that, why do we have to give them a less harmful thing?

Tess: comes back to tuning the parameters.. technological intervention to prevent it from happening is... an arms race. If we push things to the point where that happens... If we can push them to a beter place and have it be good enough that they're not going to engage in escalation then that seems like a good thing. One of the nice things about the escalation is that it's more obvious that you're doing it, then it's easier to get to a policy intervention. On the technical side, the status quo in browsers with 3p cookies is widespread cross site tracking that is technologically indistinguishable from a number of otherwise legitimate use cases. Having a mechanism like this means that those things are technologically distinguishable to some extent. It's not as good as what you were doing before - but what you were doing before is going away. So it's adopt this, or do something that's beyond the pale. If we can tune this so it's good enough that people can get 80% of what they want and not run afoul of non-technical interventions, we're hitting the sweet spot. If we push them too hard and they all just do the worst thing, then we're worse off than we were at the beginning. I feel like this is worth trying. I don't know what the end state is.

Peter: so we're not saying no

<blockquote>

We talked about this today during our call, and it's our understanding that there is a promising path forward to merge IPA, PAM and the relevant portions of ARA. Given that, we don't think it's prudent to review the details of IPA since this is subject to change.

We're happy to see these attempts to converge on a way of measuring advertising effectiveness that is more privacy preserving. We encourage you to keep fine-tuning the privacy properties of your proposals, and then to open a new design review request when it's ready and we'll take a look then. Thanks!

</blockquote>