Dan: Isn't there a competing Apple proposal? Where is this work now? https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/

Dan: is this the same thing? https://privacycg.github.io/private-click-measurement/

Dan: they have listed private click measurement in the reporting API's explainer...

Hadley: should we do a deep dive or encourage them all to converge?

Dan: I feel like there is a standards war happening here... We should be encouraging these different camps to conerge on a solution.

...There seems to be implementer support beyond Apple for Private click measurement. So why is google seeking our review?

Hadley: is it just the Blink process point, sending it to us?

Dan: and they have negative feedback from Safari

Hadley: given that i don't think it would be helpful for us to dig into the details... Where is a good venue for them all to collaborate? Perhaps the Privacy Preserving Ads CG...

determined that this is in WICG

Dan: so... what can we say?

Given that there are other competing specs from other entities that already enjoy implementation (as indicated in your Related Work section of explainers) and that at least one browser has signalled that they do not support this proposal, it seems to us that there is additional work to be done here to converge these proposals and push for a consensus approach.  Is there any effort under way to move in this direction?  Considering the numerous efforts underway by different parties, it feels like this should be headed towards a proper working group. @wseltzer

Hadley: also wondering if this should be headed for a working group.

Dan: will ping Chris H. on this as well.

Hadley: no comments back yet on our feedback.

Dan: will talk to Chris H

Sangwhan: I think these things are best discussed with the folks working on it... We could invite them for a session during London.

Dan: can you find out when they can do it and we can work our schedule around it?

Sangwhan: yes. Also they are part of privacy sandbox.

Dan: part of this session should be prioritising our time wrt to things that are provenance privacy sandbox

Hadley: [leaves comment about f2f london]

Amy: there are three explainers that all go straight into the technical solutions without user needs, and are really long. I don't know how they fit together.

Dan: leaves comment

Dan: new stuff in the explainer around motivation...... Webkit standards position still has concerns regarding convergence with Private Click Measurement.

Amy: Also IPA..

Dan: Yes...

Amy: can we look at multi-stakeholder buy in for this, IPA and PCM?

Martin: This API is several things, which each have different properties and should be dealt with separately. We can provide that feedback. Also it's under active discussion i PATCG and no resolution has been made. Not sure it's good to spend TAG time on this

Tess: don't want to accidentally swing something that is being worked on in an engaged community

Martin: we should decline to say much, and say there are some promising prospects in this area, and encourage continuing to work in PATCG

Amy: can draft and propose close

Dan: leaves comment and leaves comment on issue 22

bump

bumped

Martin: Attended meeting in Boston (PATCG, plus some side meetings). Privacy properties of the system are "negotiable" - the web site gets to set how much privacy people get... They used "differential privacy" as a privacy mechanism. The web site can choose a number between 1 and 64 - epsilon - determines how much privacy loss there is. In their API, as a web site you can set whatever number your choose within a range. 1 is considered "fine" [by privacy community]. They also let you set it to 64 which is a big number. Meaningless in terms of privacy. Default is 10 and I don't think 10 is meaningful privacy.

Dan: and normative language of user control.

Martin: no user control. There is a trial running - and part of the trial is to determine which web sites can use the API.

Martin: event-level - you get a report for every "conversion" - with randomised response - some proportion of the events are randomized to maintain privacy ... One in 20 reports gets fuzzed.. statistically that's poor in terms of privacy .... aggregated report (with noise) .... They need more safeguards than what they've put in place.

Dan: trying to channel this into the issue.

Martin: the API is [not well designed]. If you want the browser to do anything you set particular HTTP header fields on arbitrary requests that come to your server. You put in a special formatted header field - which gets big - and then that triggers actions in the browser which goes off and does a bunch of stuff in its own - no "origins" [web security model]. My suggestion is that we defer this. Ultimately they will ship what comes out of the CG/WG. We can say "we're not going to do a complete review - but we have the following feedback - we expect a working group will go into detail on this"

Dan: is there a PATWG?

Martin: no info at this time. Team said it would happen after AC meeting.

Martin: epsilon value for their privacy reporting is 14 for evennt-level - effectively unlimited. For their aggregated one it's between 1 and 64. 64 is a joke. They are trialing. Default is 10 which I also think is not meaningful.

Dan: is there any allowance for the browser to make that choice? Like a privacy-focussed browser could dial everything down to the lowest epsilon value.

Martin: 0.001 turns out to not be very useful, a lot of noise. Discussions in patcg have prodcued a design that will allow different browsers and even different users to set differente epsilon values. The designs that we're talking about hide contributions so if you set your epsilon very low then you don't participate but to the outside world you appear to be participating fully

Dan: that's good

Martin: I like it

Dan: the issue you've raised with the default values is more about chrome's decision.. the api itself sounds like a good design

Martin: what the TAG has been asked to review is what google is shipping, their proprietary solution. It's not what's been discussed int he community group. We need to make that clear distinction. There are similarities but they're different things.

Dan: the TAG usuaully doesn't weigh in in... instead of declining to comment we could say you've asked us to review this but instead we're going to review that... giving this feedback about in this differential privacy world allowing for different browsers and users to be able to set their preferences with regard to this epsilon value could be good feedback that they need to hear. If I were using chrome, installation of a privacy preserving extension would then automatically set that value low or zero.

Martin: I'm not sure whether a browser like brave would implement this. That's a discussion I've had with peopel at brave and not got much traction on. Our intent is to implement this but have a different epsiolon value to the one google has. After the last PATCG thing we solved a lot of questions about what a merged design might look like.

Martin: there's another one used in the context of protected audience which is separate from these but similar.. I don't think they've asked us for that

Martin: Microsoft might object to this characterization of multi-implementer interest. I don't know if they back this proposal.

Dan: we propose to close this one as resolution: decline. - let's take it to the plenary.

We expect the Private Measurement API being developed in PATCG will receive multi-implementer interest. Our initial read of that is that its design is broadly reasonable.

Dan: bump to the f2f - as it's part of a wider discussion on Privacy Sandbox and we need to have a separate session on it and other privacy sandbox things...

Hadley: I'd like to be a part of that, if I can

Dan: We'll try to put it on the agenda for a morning slot then

DP parameters

Martin: explains differential privacy

Dan: attribution reporting.. epsilon value is supposed to be small but ..

Martin: no agreement on epsilon values. Different epsilon values can mean differentiation between browsers.

Peter: should we even do this?

Martin: spirited defence of attribution reporting

Peter: Technology in the UA that is not acting on the user's behalf ... so may not meet the threshold for me personally...

Martin: there are a number of ways that this could be much worse... ... is there a collective benefit that is obtained through the use of this ... so we still offer individual choice... these matters are really complex - having a specialised governance bodies decide ... Is there a collective benefit to having this kind of capability.

Peter: I don't think the ad industry have a right to it.

Martin: but they may deserve it. The argument : there is a lot of content out there supported by advertising. the quality of the support degrades if you take away these capabilities. The rich people who see the ads and buy stuff subsidize the content.

Peter: I hear you. I am not anti-advertising. However there are a whole separate set of people who benefit from advertising that are just a vector.

Martin: this is where protected audience comes into the conversation...

Peter: worried about trading one horrible thing for another slightly less horrible thing. So what is the path to the next step?

Martin: next step for me is much tighter restrictions...

Peter: we need to do this incrementally... won't block something I think is a reasonable step... but worried it becomes the end state.

Martin: one of the nice things about this - it places a knob in our hands - dial up or down - you personally have a dial. You can set it to whatever.

Dan: is that mandated?

Martin: good reception to that...

Peter: my concern : this thing is not ideal but good enough - but people who want to abuse it can tie it with something else and then we're back where we started.

Martin: you can cut one campaign into two campaigns... I'm advertising to who I think are women or who i think are men - and then you have info about those groups... if you keep subdividing you are learning things about subsets of the populace - and that is targeting. However all ads are targeted in some way.

targeting through the ages

Discussion of political advertising... as a negative use case.

Yves: There is a reason advertising targeted to children is forbidden in some countries.

Martin: I would like to encoyeage folks to continue their engagement in PAT xG.. but more or less decline to review... We can provide feedback about privacy parameters...

Tess: I think that's basically right. CMA asked them to make ... a change... we could pile on and say the same thing... the thing I want to encourage: I've been impressed by the convergence between the 3 proposals... I'd like them to keep doing that. This should be one thing.

Martin: the oucome where there are propeatary APIs in each browser for this is a bad outcome. Particularl for [small market share browsers].

Dan: the parameter... should be available to the end user ...

Martin: worried about ... that's in the relationship between browsers and their users...

Tess: i see your point, Dan, but I don't think TAG can ask us to have a ..

Dan: we could say in our feedback to encourage the spec to include language to encourage implementations to put the user in control. In line with Privacy Principles....

Tess: could be a range ... if we worded that in a way to require browser to allow the user to access the entire range, there could be values that are not acceptable from a ...

Dan: also not detectable when you turn it off..

Martin: that's already inccorporated.

consensus to close this on this basis

Martin: aggregated vs. disaggretated?

Tess: i'd be inclined to prioritising aggregated.

We encourage the proponents of this work to continue engaging in the discussions in PATCG (eventually PATWG). The work there on aggregated solutions seems to be making significant progress, and we hope that you will succeed in converging on a single, consensus-based approach.

We are formally marking this request as "declined" because of the ongoing work. We're otherwise supportive.