Taking up Topics API for Next Meeting or Future Meeting?

[AramZS]

Should this group take up Topics API?

As discussed we wanted to be clear here if we, as a group, feel Topics API is a proposal that fits well within the mission of this group and makes sense for us to take up. There are three considerations that I'd like to discuss in this thread:

1. Is this the place to discuss this proposal to give it airtime for discussion (ad hoc or main meeting), with the intent that it may eventually be output as part of a larger report from this group (which grants it IPR protection)?
2. Is the submitted Topics API a good basis for this group to move towards a formal Community Group Report on this standard?
3. Should we take up Topics API in the next formal meeting or (for now) through ad-hoc discussions?

If the answer to all three of these questions are no then we should suggest Topics API move to another group. At request, we would like to resolve this question by EOD of the 21st of this month.

Links

Here is the submission to our group - patcg/proposals#4
Here is the proposal - https://github.com/jkarlin/topics

[dmarti]

1. Yes, this group could be a good place to discuss Topics API, probably the best fit of any of the W3C groups.

2. No, the Topics API repository currently has 41 open issues, many of which, depending on how they get resolved, would have a big impact on how practical or desirable this proposal would be to implement (especially for sites that cover only one or a few topics and for callers that are present on few domains)

3. No, it does not look like a meeting would be productive at this stage in the process. (The unresolved "niche site vs. general-interest site" and "rare caller vs. widely used caller" concerns would be likely to take up too much time, and that time could be saved by addressing some of the existing issues before a meeting and not afterward.)

[bmayd]

I agree with @dmarti on all the first two points.

Regarding whether we take it up in the next formal meeting: if we want this group to be broadly supportive of efforts to develop privacy-preserving advertising technologies, as I believe is the general intent, we will want to be thoughtful about giving proposals attention in a timely manner. I have concerns that if the group becomes too involved with a specific aspect of advertising, those interested in pursing efforts in other areas will seek alternate venues and we will fail to capitalize on the potential for this group to unify and consolidate the community's efforts.

As a case in point, if we don't provide airtime for Topics, we put the proposers in a position in which they have to decide whether to wait until we're ready, or pursue the effort independent of this group. I'm confident the latter would be the case and that, rather than becoming the promised point of convergence I think we were all wanting PATCG to be, this group would be yet another of the may places where part of the work is done.

Using formal meetings like we did the first one: to inform the larger group about a problem space and some of the ways in which it is being approached, then using subgroups to further develop things, seems like it provides the best balance of knowing what could be worked on and doing the work. In light of that, I suggest we crowdsource other broad topics, akin to the "attribution" topic of the first meeting, and figure out how we go about deciding when we might make them the agenda topics. Doing this will give those pursuing proposals like Topics, and the community, useful information for deciding if and when this is the right place to engage.

To be clear, I did hear the pleas to focus on attribution so that meaningful progress can be made and I agree with that sentiment, but I think we have the capacity and diversity of expertise to pursue multiple work-streams in parallel and make progress across them. While I would venture the majority of us are interested in, and supportive of, solving attribution as a prime objective, I'm confident many don't have the inclination or capacity to make significant contributions to the effort, but would be willing and able to pursue something else and I think we would do well to cultivate other domains where they can make contributions while attribution gets advanced.

[dmarti]

I agree with @bmayd that this group should be able to work on multiple work-streams. This group will probably turn out to be the best place to discuss Topics API.

A 15-minute agenda item for 80 people is 20 person-hours, so it would be most productive to add Topics API to the agenda after the significant existing issues are either fixed, or the proposal is updated with more info on why the issues are being closed. Bringing this proposal to the meeting in its current state is likely to turn the meeting into a not very productive reiteration of already-posted material.

[npdoty]

1. Yes, +1 that PATCG is an appropriate venue for Topics API (and related topics proposals) work and that it would be good to work on it here.

2. I'm not exactly sure what the criteria are for "a good basis". I think there's lots of work to be done and alternatives to consider, but I'm fine with starting with the Topics API and/or the Ad Topic Hints work since they have been directly proposed.

3. I don't have strong feelings either way on whether this should be a meeting agenda item or done in a subgroup or via github. I could see an agenda item on a larger meeting to present some potential options, gather a little feedback and then move to ongoing subgroup meetings. But also I suspect there's a lot of ideas and discussion that can happen in a subgroup or github issues already.

[martinthomson]

This group should provide a venue for discussing these proposals. They are in scope.

It should not adopt them until we have greater confidence, collectively, about a proposal. Confidence about whether we are ready to commit the time to working on that proposal. Confidence about the solutions being appropriate. Confidence that the proposal makes some advertising use case better. Confidence that the technical privacy protections in the proposals are effective. Confidence that the proposal represents the best choice from the space of available options.

I'm not asking for 100% on any axis, but we should spend some time with these proposals before we make any decision.

With respect to reserving time, I worry that allocating time at meetings will divert limited resources away from more important work (measurement/attribution/...). Anything we do here needs to consider the potential for damaging progress on other work.

[jkarlin]

It sounds like there is support to at least discuss the proposal. Should we move the github repo into patcg while that discussion is happening?

[ekr]

No, we definitely should not do that. Github repos should only be in PATCG once the proposal is adopted as something we are working on.

…

On Thu, Mar 3, 2022 at 8:16 AM Josh Karlin ***@***.***> wrote: It sounds like there is support to at least discuss the proposal. Should we move the github repo into patcg while that discussion is happening? — Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPLIMGRWLH5REMG4JEOL3U6DQUTANCNFSM5OFVTTKA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AramZS]

To all in this thread:

The discussion on the issue at patcg/proposals#4 has moved forward towards the idea that we should support an incubation phase and help organize in-scope proposals like Topics API through that process. I have proposed an amendment to the charter to support that and added a call for consensus on that issue. Please provide feedback as needed so we can move forward - patcg/patcg.github.io#7

[jwrosewell]

Google and CMA reached an agreement on 4th February 2022 concerning Privacy Sandbox and Topics. The agreement requires Google to train staff in Annex 3, and paragraph 4.119 states, “Google has committed to instruct its staff and agents not to make claims to other market players that contradict the commitments, and to provide training to its relevant staff and agents to ensure that they are aware of the requirements of the Final Commitments”.

@cwilso @jkarlin has this training been complete?

Paragraph 21 of the agreement states “During the standstill period, the CMA may notify Google that competition law concerns remain such that the Purpose of the Commitments will not be achieved. Google will work with the CMA without delay to seek to resolve concerns raised and address comments made by the CMA with a view to achieving the Purpose of the Commitments. Google will inform the CMA of how it has responded to those comments”. Topics is explicitly covered by the agreement. Spending time discussing or developing the Topics proposal in PATCG, or anywhere else, will either a) fragment the web as Google will not be allowed by the CMA to implement the proposal; or b) merely waste our collective effort and time delaying the realisation of benefits via other proposals.

For Topics to become acceptable under the agreement parties other than a web browser will need to able to implement it. As a minimum the current text from @jkarlin will need to be modified to ensure that it can be implemented by any participant and not just user agent vendors.

@cwilso @jkarlin have Google verified with the CMA that the proposal meets the CMA’s requirements? If not, I would prefer that CMA provisional approval is obtained before doing any further work to avoid a) wasting participants time that could be better spent on other work; and b) distorting the market via communication that does not comply with the agreement.

Further, I was at a meeting of advertising and publishing executives (non-technical) last week. All were aware of Topics, proving that market communication is occurring. The consensus of the meeting is that Topics was “utterly useless”.

Finally, the Topics proposal does not meet the Antitrust Guidelines of the W3C. This has been covered elsewhere.

For those wishing to better understand the agreed commitments an explanation has been produced by Movement for an Open Web (MOW).

[AramZS]

@jwrosewell since you are not an agent of the CMA and I must assume that all participants, including Google, are acting in good faith, and we've already had an explanation from the W3C that I take to indicate that incubation--in general--is a known process I cannot effectively preempt some theoretical CMA action. Nor can I take into account your representation of voices that are free to participate here but have, thus far, not spoken up. (Unlike in the BG or a WG dedicated W3C membership is not a requirement for participation here.) That said, even taking it into account, the goal of bringing the Topics API into an incubation process would be specifically to make it more useful, which would presumably address those concerns. Until these other voices weigh in here in public I cannot take your representation of them as any larger then your individual role in the consensus process.

As you can see in patcg/proposals#4 we're looking at the Topics proposal for incubation specifically in order for it to be discussed and evolved to the state that it becomes implementable which acknowledges that any proposal in the current state is entering into incubation specifically in order to discuss how to get it to become generally agreed upon as implementable, a process that we all--I think--would agree makes sense as multi-party and in the open.

I see your objections here, however, since they are not technical, I don't think they are of any relevance unless the CMA feels it has grounds to intercede. Additionally, as I'm not a lawyer and no W3C lawyer has told me otherwise, I have to assume that the Topics proposal does not violate the Antitrust Guidelines. Beyond your claim, I have no particular ground to judge it as such and would require some agent of the W3C to make a clear statement otherwise. Until I see either intercession, I can't accept this argument as a reason to cut off all discussion.

If you feel you have objections to the proposed process of incubation within this group, please put them on the PR in respect to your objections to that specific process.

In either case, this issue has been re-added to the Agenda on the grounds that we will discuss the status of what we're going to do as a group with the Topics API, not discuss the API itself. It is unclear what that will be at the time of writing because we have not reached consensus on either the incubation process or the state of the proposal.

If you believe the Topics API represents a violation of some promised Google action through the act of proposing it, then the right place to take up that is on the proposal itself not here. If you have specific disagreements with the W3C's general processes I understand that you, through MOW, are actively pursuing them already in a more appropriate venue. This location is not the correct place for either of those complaints as we are not equipped with either the process or operating leverage to act on them.

[jwrosewell]

@AramZS I agree that this is not a matter for PATCG chairs to decide on. The comment was directed towards Google's representatives @cwilso and @jkarlin to request that they assure other participants they have approval from the CMA to advance the proposal as drafted. Without such an assurance they will merely be wasting everyone's time and I hope you will agree that this is not an efficient use of people's time.

As PATCG chair you may wish to determine if W3C legal advice has changed since 1st February 2022 following the publication of the commitments.

For the avoidance of doubt I believe the proposal can easily be modified so that any party can have access to the input data and then decide if they wish to implement the Topics proposal, or any other proposal using that input data. Without such a modification all I can do is noisily complain and highlight the issue.

[wseltzer]

@jwrosewell You have been asked to stop this thread of conversation. Please do.

[AramZS]

Now we have a methodology for bringing such a proposal in for discussion via the Individual Documents process. As such, this issue is resolved.