Lola: I was under the impression that there was no longer attribution.

Brian: I've been looking at this. It's kind of complicated. There's a lot there and a lot of history and a lot of controversy. A lot of pushback on their mailing list. It kind of bifurcates the conversation. One thing I noted in the issue that I don't understand: they have this thing were you have to choose--basically there's a service in the browser that's exposed that will record impressions, basically. You want to say, "they were shown this ad." It records these things locally. Then, a little like the report-only feature in CSP (not right this second, but it will batch and send to a service so it can't be tied to you or a specific time or event). It exposes a collection of URLs that are the service endpoints where the data will ultimately be sent. Thebrowser ships with support, or it has to go get support from somewhere (a third-party service like Mozilla). You have to pick one of those URLs. The obvious choice is to pick the zeroeth one. They allow for fallback options. But then they have a thing where you can provide a URL. I don't understand why. They say if you give a random URL, it won't work; it has to be in a list.. It feels similar to a lot of other things we've tried to standardize in the web platform that have been miserable, like voices in Web Speech. I'm curious about that particular design decision.

Matthew: I can't answer that directly, though I'll definitely look into it.

Jeffrey: The usual reason to do this is that the web service needs to trust one of the services (that's what happens in Federation). I don't know if that applies here. If there's not a "website trust" decision, then that would be appropriate. The browser supports certain servers. The Website can decide, "I trust these bu tI don't trust those". The website may not trust everything that the browser trusts (since the browser is the user's agent).

Brian: It's not the negotiation that I have a prolem with. It's that you have to provide a URL that has to be present in the browser list. Why not tive you back some thing that represents the service opaquley. It says "service URL", but you can only supply whichever one which happens to be present in that browser .All of the things that effect the available voices for web voices apply here, too

Jeffrey: This shows up in payments, too. The payment providers and the underlying contracts. It's also just a string.

Lola: An explainer would have helped with that. We need to tell them to write an explainer for this.

Matthew: I had a different question, more basic. .I'm aware of three proposal for attribution reporting: Googgle's for privacy sandbox, Mozilla and Meta had one (IPA, I believe), and Apple had one which was PAM (private attribution monitoring). Google's has two parts: a batched differential privacy part and a more real-time part (more privacy leakage but more info for advertisers). The others don't have the real-time part--just the batched part. My understanding is that Google's w/o real-time and the other two are very similar, and that this is an attempt to harmonize. I don't see Apple participating here, though, so I don't know where they stand.

Brian: There's a web-standards position open for it. It doesn' thave a position, yet, though. We know that Mozilla (in the sense of the people working on it) are supportive. It'd be a surprise if they changed. I don't know about Apple.

Jeffrey: I think they've been participating, but I can't find a source for that.

Lola: We can ask Marcos in Slac.

Brian: Nothing new from me this week, I made comments last week and I think heather and essan were going to

Matthew: There is a meeting in PATWG tomorrow, I will ask essan if he is willing to attend, people in the states might find it easier to attend - it will be a kind of open house where you can ask questions. I was just wonderin gif the harmonization they were talking about had happened - we don't see people in apple in the spec, and there was no standard position. It is IPA vs PAM and they were merged together - but at least half of this is differential privacy, google has this extre bit - events which is less privacy preserving, and there are Google people in on this. It is promising and seems like maybe some concensus is reached

Lola: If you find something, or learn something else please share it in slack.

Marcos: Will check to see if there is a WebKit position published on this

(Skipped.)

Heather: I looked at this and posted a few questions in brainstorming. Had some about whether I was reading it correctly and if this is turning browsers into advertising data processors, and whether we are OK with that, as it seems like a big leap in terms of what browsers do.

... Also some decisions like making empty allowlists meaning global permissions, which seems inconsistent with the rest of the platform, and general convention, and thus concerning.

Heather: I need to get some quality time with Brian on this.