It shouldn't be the browser's job to help advertisers

[kuba-orlik]

I feel like the Topics API is specific to one industry (ads), and browsers should be only concerned with technology, not for-profit

I see two dangerous trends that Topics API could start/accelerate:

• browsers being less and less of a UserAgent. The browser should represent the User. So it should only be concerned with the User's goals and interests, not with helping the advertising industry.

• Industry-specific solutions in the browser. I believe that APIs provided by the browser should be about specific technologies. Topics API isn't about technology, it's about helping the ad industry. A slightly exaggerate slippery slope consequence of such trend could be other domain-specific APIs: maybe some API specific for websites that do auction-style listings? Or a browser API for authenticating users in websites under the microsoft.com domain?

[dmarti]

Topics API is not really specific to one industry. Although the current focus is on advertising and publishing, any domain can call it. Topics API could end up being more useful for other kinds of functionality, such as dynamic or personalized pricing by retail and travel sites. (https://github.com/patcg-individual-drafts/topics/issues/34, https://github.com/WICG/floc/issues/105)

[michaelkleber]

Hi @kuba-orlik: Browsers include a bunch of APIs that make it possible to do things on the web in a way that is more private or secure than how that same thing could be done without dedicated browser treatment. The removal of third-party cookies makes some of those APIs even more important than they have been in the past.

Federated Credential Management for better sign-in, or support for Web Payments via the Payment Request API, are examples unrelated to the ads industry. These don't seem like a slippery slope to me, they seem like the development of the web working as intended.

Browsers absolutely do need to act as User Agents, as you say. But they also need to pay attention to the needs of the people who create websites — those are the users of the web platform, and if we ignore their needs then we risk the incredible richness that the web has become. This is deeply in the interest of people who visit websites also, though certainly in a more roundabout way.

[dmarti]

@michaelkleber It's an oversimplification to represent Topics API as something that addresses the needs of "people who create websites." The general flows of topics data, and resulting value, are

• away from smaller sites that cover one or a few topics toward larger, general-interest sites such as YouTube
• away from sites on which advertisers would choose to have their ad run, and toward sites they would not choose

There may be a need for allowing users who want to share their interests to pass some interest information to sites on first visit. But it would be more productive to address that issue specifically than incidentally as part of an API that also supports less desirable data flows and creates incentives for less desirable activiies. More: Google’s Topics API Picks On Smaller Publishers

[michaelkleber]

@dmarti: I'm aware of your beliefs about who benefits from the Topics API, and I think you are mostly incorrect. But our disagreement about this doesn't seem relevant to @kuba-orlik's basic point that Topics API is primarily designed for web developers.

[dmarti]

@michaelkleber Looking at the original issue, @kuba-orlik has two main points. First, does this mean moving away from the browser as the agent of the user? It looks like the answer to this question would depend on what the user's intent really is. I don't see any user research that indicates that because somebody clicks on a web link, that always means they are willing to share their interests with the site. It would be really helpful to link to research in this area from this proposal.

Second, is this an industry-specific solution? Does not look like it is. There are many other parties besides advertisers who would want to be able to classify users by interest, even imperfectly with random noise.

• LMSs classifying likely diligent and distracted students for recommending extra teacher attention
  • Airport security classifying likely firearms owners for an extra check (most weapons found at security were accidentally left in a bag)
  • Tax authorities selecting taxpayers for audits (some jurisdictions could require a public sector caller for online retailers doing business there)
  • Property management firms selecting likely noisy tenants for extra checks based on noisy or quiet interests

We can't know all of them in advance. There are going to be a lot more of these situations where Topics API data feeds into some kind of score to select people for some kind of attention (good or bad) so I disagree with @kuba-orlik that this is an industry-specific solution. Because it has different privacy properties from third-party cookies, Topics API will be applicable in some situations where third-party cookies are not, and vice versa. Topics API looks like a fundamental change to what it means to click on a link, and will end up affecting many more kinds of sites than just advertiser and publisher sites.

[siliconvoodoo]

Brave has expressed extensively how none of this effort is in user's interest. This is for monetization on the back of the users. If the browser becomes an identifier agent, it becomes a snitch, no more no less. Stop participating in creating dystopia on this society, your lack of responsible concern is why we can't have nice things. https://brave.com/web-standards-at-brave/7-googles-topics-api/