Re: [w3ctag/design-reviews] Early design review for the Topics API (Issue #726)

Thanks for the feedback. I’ve added responses to both plinss and cynthia below:

> Do you have a response to the points raised in [Webkit's review](https://github.com/WebKit/standards-positions/issues/111#issuecomment-1359609317)?

They are similar in nature to what has already been brought up by TAG and discussed in this thread. If there are particular questions I’d be happy to respond.




> Do you have any analysis or response to the papers that Martin pointed to?

Yes, please see [my previous comment](https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1610196715). To add to that, I think it’s important to understand that all of the papers are using different data sets with different modeling assumptions on evolution of user interests, number of users present etc. Our own research utilized real user data, while the others understandably had to generate synthetic web traces and interests, which Jha et al. notes may not be representative of the general population. Nonetheless, they all found that it took a large number of epochs to reidentify the majority of users across sites. 


> Please could you elaborate if it is in fact the case that all sites browsed by a user are included by default as input data for generating a user's topics list? If this is the case, what recourse is there for sites which are misclassified?

This is not the case. Only sites that call the API are included as input to generating the user’s topics list.




> Can you clarify the situation with regard to definition of user preference / opt out?

Users can opt out of the API wholesale within Chrome's privacy preferences. They can also disable topics that have been selected. In the [future](https://developer.chrome.com/blog/topics-enhancements/#user-controls), they will be able to preemptively remove topics.


Sites can choose not to use the API, in which case user visits to their site will not be included in topics calculation. Sites can further ensure that nobody on their site calls the API via [permission policy](https://patcg-individual-drafts.github.io/topics/#permissions-policy-integration-header).




> Have you considered dropping the part where topics are calculated from browsing history, and instead entirely configured by the user in their browser settings? This would be much closer to people being able to meaningfully opt in to targeted advertising, and would make several of the other concerns raised moot.

It’s been raised in our public meetings. Folks have raised multiple issues with such an approach. One is that user interests are dynamic, whereas settings are generally quite static. A second is that it seems like many users might not bother to configure this, even if doing so would improve their ads and the revenue of the sites they visit. 



> This leaves document as the natural location for access via the browsing context. One question on the API surface would be whether there would be a reason to access topics from a worker (e.g. for background/off-thread/SW-based bidding), in which case you would probably want to expose it to WorkerGlobalScope as well. We don't know if it would be a critical use case, but if the ad tax in the main thread can go down as a side effect of this, it would be worth considering.

Excellent, thanks for that guidance. It seems reasonable to expose the API to `WorkerGlobalScope`but I don’t think it would alleviate any main thread costs, as the browsingTopics call itself is asynchronous and efficient. If developers start to ask for it, then we can consider adding it more seriously.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1662735894
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/726/1662735894@github.com>