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.

Heather: I'm unclear on what I'm supposed to review at this point, given we've asked for an explainer.

Brian: I think this is tied into conversations about Global Components. Talked with James Roswell about this at the Meet the TAG event. Two issues arising. One is that this really could use an Explainer. I commented on this; group is taking it into consideration. As Heather said, this is a big change to what you'd expect out of a UA.

Lola: Typically if there's no Explainer, we wait to review until there is one. This is a big spec, would be very helpful to have one, say what the user benefit is, what the impact is, who's involved, etc. If they're going to write one, we should wait.

Brian: Separate Explainer not required by the Process; they say that the first part of the doc is equivalent to the Explaienr, but I think it's not adequate. Some disagreement in the AC as to whether an Explainer is required for a spec that's undergone incubation.

Lola: If there are specific sections (like the Considerations, and Alternatives Considered) that we would not expect in the spec, that are missing, we should ask for them to be included.

Brian: I think I've put this across to them, Explainers aren't just for TAG. Lots of people across the industry will want to know about this. Especiallly for this, an Explainer would be really good. Some people have been able to use Claude to create a starting point for Explainer from the doc that was good. I tried this and gave it to them, and encouraged them to edit it to improve it without spending much time on it.

Matthew: (That's awesome, Brian--to be the change that you want to see in the world.) I don't wnt to derail this conversation too much, but an item I haven't spoken about with anyone is tied in with explainers and also the CRA. Jeffrey was probably way ahead of me on this before he went on leave. Architectural decision records (ADRs) would probably be in-line with the CRA. I'd love ot see a spreadsheet with agenda ideas, but I guess we're get there at some point. It's difficult to collect them in a GitHub issue.

Lola: Yes, we're collecting things for the F2F in a number of different ways, so we'll have to consolidate them at some point.

Luke: I think we need to push back when groups put the spec forward as the explainer. Many people need it for reviewing purposes. We shouldn't all need to burn through water and resources to generate one. Anchor Positioning for CSS was another that could have benefited from this - I'm sure there are many more specs that I would understand a lot better after reading the Explainer. Especially for Attribution. It's doing a specific thing in a specific way, but there are already around six different implementations around the web; this would be an important Alternatives Considerd section.

Lola: Likewise with DID Resolution - it's challenging to review without the Explainer. I think it's fine that you've given them a starting point, Brian, but we shouldn't have to keep doing this. May have been good to speak with Dan Appelquist about this, as IIRC he championed Explainers.

Brian: Yeah, around 2014 or so.

Lola: If there are Explainer sections that are not in the spec, we should ask for those at least. Please do ask.

Brian: Having the generated one is better than not.

Heather: I always assumed I needed both - the Explainer helps me get started, and the spec provides the detail.

Sarven: Some of the reviews I do, I make use of the Explaienr first; on others I dive into the spec first. Sometimes I don't rely on the Explainer as it's not as authorititive as the spec. For one, I sensed the Explainer was machine-generated, and I read the spec, and the issues they had for it helped me understand what the group was up to. This is just for me, nothing general for every person and spec.

Lola: They're not a replacement for a spec, but are good as a primer. Sometimes the Explainer is poorly written and needs work.

Lola: Should we wait for them to create one, or use Brian's generated one?

Brian: For me I think the comments I have are nothing that they wouldn't've heard already. This is a whole new ball of wax - responsibility for UAs - it's unusual in ways that I think are not great. It copies some design mistakes from Web Speech, to me. I don't think on purpose, but has some similarties that are not good. I have reservations about the whole thing that are not just architectural.

Lola: Should put that in a comment. Helps to know what TAG thought at a specific time. Please draft a proposed comment and we can review it.

Matthew: Ehsan's on this one, and I've looked a bit, as well. I think we might have some questions for them, but I need to sync up with Ehsan, first. I might be able to do that before tomorrow's call. I would like to review the comment (and maybe contribute to it) before it goes out.

Brian: I think questions would be a good first step. I think the comments we have are relatively shallow. Most of my questions/thoughts... need to dig more into how I think about some of these more centralised global things that we are putting in the browser. That's why I was reaching out about the Global Components discussion. Not exactly related, but one may inform the other.

Lola: Sounds like two things to me, how these things fit into the architecture of the web, however this isn't the first time when we've been in that kind of situation. I wouldn't hold off on commenting on this review until we've had that bigger discussion.

Heather: +1. I want to have that Global Components conversation because I don't see the thread that you do, Brian, so I'm interested in that. That's probably an hour or two of our f2f but I don't think this review can wait that long. Happy to push back with the questions I have, and requesting an Explainer before we dive in.

Brian: Sounds good.

Lola: This was discussed in the Privacy Working Group last week, and there was a lot of discussion, actually. The propoonents of the proposal were also in the call.

Ehsan: They have not released the minutes as of one hour ago.

Lola: The overall vibe is not positive in terms of support from the Privacy Working Group. Quite a few folks spoke out against it for various reasons (including me, not as a TAG representative).

Luke: Were most of the objections a more philosophical? "We don't want this capability on the web?" Or was it about the implementation?

Lola: It was a mixture. There was a revieew of the specification which arrived via e-mail. That was more philosophical ("this is technically a good specification, but I object bringing it to the web"). Then there was a contingent that objected to standardizing industry practices if those practices are not beneficial to the user. I think that there is some techincal critique, but that there is also philosophical objection. It went on so long that we had to table it. The call was charged because we also talked about WebMCP. In both cases, they suggested that they could have a separate session with TAG.

Brian: Martin is one of the people who worked on the spec, and he was on TAG. It seems like he must have thought about users. It does feel like, in a sense, they are doing what they can to protect privacy (versus the status quo). It is better for users and worse along the business-practices lines. I'd like to read the conversation, but a thing that was recently brought up is that it is poorly-named.

Lola: Martin wasn't present on that call, for what its worth.

Lola: I raised a question that Heather had about the allow-list. That was what they said they will let the browsers handle. They don't want to dictate the UI. I said that the allow-list isn't about the UI. If there is a star in the allow-list, what happens to the actual permissions (not the permission box, but the wiring underneath it). The minutes are very paraphrased, so you might not get the nuance fo the meeting.

Ehsan: the core of my concern is that architecturally on paper, it looks okay, and the algorithms are well-established by credible cryptographers. I don't have any problem with teh core foundation. The devil is in the details. There are arbitrarily/loosely defined etails that leave a lot to the user-agents, and they can be very important in this matter. At the end of the day, we want someting that preserves privacy an that works well. I understan that there are a lot of frustrations around the model of advertising, but at the end of the day, the status quo is different from what TAG is advocating. We need to leave some room for innovations without blocking the whole thing. I understand there are frustrations, but I think it's an improvement over the status quo. That's a summary of my upcoming comment in the private brain storm.

Lola: I agree that I don't think TAG shouldn't prevent innovation, and I think that's something wihtin the W3C that various groups are wrestling with (not just the TAG). However, there is definitely an attritude of standardizing industry practice, and I don't think that's the right move, either. "The industry already does this, anyway, so we might as well, too." The industry does what it wants, often at the disadvantage of web users. That's what the TAG exists to guard against, after all. I think we need to think about the opportunity for abuse. Within the specification of third-party cookies, there is a direct call-out not to use it for tracking, yet that is still the primary use-case for third-party cookies. It falls on us to not only ask, "Does this improve the status quo" but also "is it beneficial for users?"

(Ending meeting here for lack of time)

skip