unfair restriction on topics filtering per caller

[jdelhommeau]

It seems quite unfair to be limiting the list of topics returned to a caller based on that caller presence on sites mapped to those same topics. This will create a large entry barrier for smaller actors, who will have a hard time accessing less common topics, vs large actors, such as Google, who already benefit from a very large foot print and won't be limited at all. It also seems weird to defend that mechanism on the base of not providing more data than what cookies would provide, when same principle is not enforced on other proposals. For example, conversion measurement API will provide cross device functionality, which wasn't possible using third party cookies. One could argue that this is more privacy invasive as well. Third party cookies shouldn't be used as the benchmark for privacy. Rather, we should consider whether such feature is following privacy expectation from users, or regulation's principle such as GDPR. Seems like it would be more confusing for a user to know which topics he belongs to, but not knowing which callers can access them, vs simply providing all callers with same level of access.

[dmarti]

Related/possible duplicate: #11

[jkarlin]

We want to make obviously positive steps forward for privacy. If we deliver less data to more people compared to cookies, it becomes difficult to weigh the privacy benefit. Mozilla stated this plainly in their Privacy Analysis of FLoC: "The end result here is that any site will be able to learn a lot about you with far less effort than they would need to expend today."

[jdelhommeau]

Again, it really depends how you conceive privacy. If you look at GDPR, some of the pillars in the definition of privacy is transparency and control. This kind of filter removes transparency form the user. Providing more data, in the end resulting in greater experience for the user, while providing full control to the user of topics he belongs to and whether to share them or not seems good from a user's privacy. OF course, this means that Chrome will need to make it more explicit to the user what is happening, vs the current "privacy sandbox feature" hidden in privacy menu and opt-in by default. Really depends where you put the cursor... In the end, the current filter only results in higher entry barrier for new comers.

[dmarti]

Also see #11 -- a third party that is not a caller of Topics API can still be a recipient of topics for the current user, if a caller passes topics to them.

SSPs then take what they know about the site/visit, whether supplied by Prebid library or their own header bidding wrapper, which would now include the Topic(s) shared by the API, and use it to populate an ad request out to one or many DSPs.

It's not really obvious to the user which sites would have topics based on their history of visiting which other sites.

[jkarlin]

In the end, the current filter only results in higher entry barrier for new comers.

It's not higher. It's the same barrier of entry as we have today with third-party cookies. And that's the point. We can't take a step backwards in privacy here.

[martinthomson]

Characterizing this as "no higher" is somewhat disingenuous as the net effect is that the information being presented is only available to those who have sufficient presence. That's a bias toward incumbency.

If the claim is that access to this information degrades privacy significantly, then we should maybe consider not providing it at all. I appreciate that Google (Chrome) have chosen to adopt a different reference point for making that assessment, which makes this a particularly challenging assessment.

However, I'm seeing a different argument being put forth at the same time. That argument says that some release of information about interests has a small, but maybe acceptable, privacy impact. I'll have more to say on that in time, but if this is the privacy basis of this proposal, it is hard to see why you would need to construct an API that also privileges services with extensive reach.

I don't see how both arguments can concurrently exist without each undermining the other. Unless...

There is perhaps a different line of argumentation that might be used here: this is a transitional technology that is deployed with the intent of weaning the industry off a dependency on interest-based targeting. A proposal that was made in that spirit would have progressively tighter restrictions[^1] with the goal of eventually being removed. With the constraint that the API might eventually become useless - which I don't see, to be clear - you might see how you can reconcile both worse privacy and competition effects.

[^1]: Degradation options seem possible. The 5% of randomized responses could be increased gradually over time. Topics might be progressively merged so that they provide less information.

[jkarlin]

The rationale is really as simple as I'm saying. With FLoC, it was challenging to show that we were making a step forward in privacy. FLoC provided less data (privacy good) but to more parties (privacy bad). How does one calculate the net privacy win or loss of that compared to the status quo of third party cookies? By restricting to the capabilities of third-party cookies, we can clearly state that we're making a step in the right direction.

There is a caveat however, which is that it's not a perfect subset of third-party cookie behavior. We do still leak that it's a user's top topic, which is new information. I'd like to remove that but am not sure how we can without opening up the API to fingerprinting abuse.

[dmarti]

There are ways to address both the bias toward incumbency problem and the need to limit to a subset of the functionality of third-party cookies. For example. the browser could increase the probability that random topics will be returned to frequent callers.

• keep a list of the n most recent calling domains
• when Topics API is called, select m domains from the list at random. If the current caller matches any of them, return random topics
  • otherwise return random topics 5% of the time.

[rodolpheAV]

It's not higher. It's the same barrier of entry as we have today with third-party cookies. And that's the point.

Even if I understand the aim of this restriction, you're not right when you consider that it would lead to the same privacy restriction than the one we have today with cookies. It would actually be a major restriciton.

Today with cookies an AdTech A have its own footprint on the web and can collect data based on it. Using Cookie matching with an AdTech B which has its own footprint, AdTech A can then broaden its targeting as it can observe more touchpoints of the final user.

This is typically what's happening with SSP and DSP cooperation. SSPs are integrated on publisher websites and DSPs on advertiser websites. A DSP can infer which user or publisher should be targeted for an ad campaign because it can observe users interest based on its footprint but also on the SSP footprint using cookie syncs.

Therefore, restriting topics access based on the caller presence is equivalent to removing the Cookie matching mechanism in the curent workflow. This would lead to a much lower targeting capabilities especially for small actors or newcomers in the market.

Transposing at the SSP/DSP cooperation with this proposal, an independent SSP would only receive topics related to publishers (mainly news and entertainements topics), and an independant DSP would receive topics related to the advertisers they are working with (let's say goods realted topics). It's quite clear that a big company operating an adTech platform containing a SSP and a DSP would benefit from the situation compared to smaller companies as it would have the ability to analyse topics corrélations and process much more precise targeting strategies.

This situation would actually force small actors to cooperate against bigest favoured others and lead them to the issue #73