Comment by chrismorgan
3 years ago
Although the source article here is clearly opinionated in one direction, I’m not impressed with your claims about actual problems in it. (For reference, I agree with the direction it takes and would make only minor adjustments to it if I were writing it—the only of any substance would be not calling the Privacy Sandbox an “ad platform” just because in a way it’s a little more like a shop that sells picks to ad platforms.)
> 1. Privacy Sandbox is a project, consisting of many proposals. To pitch it as some cohesive product is misleading.
Look, that’s how Google are branding it. It’s an initiative which has turned into a cohesive brand. Just look at how https://privacysandbox.com/news/privacy-sandbox-for-the-web-... speaks of it all. That’s pretty much how it’s being presented in the browser, too.
> 2. Related: FLoC and Topics are completely separate things, aside from existing under the same project.
They’re about as completely separate as Chrome 17 and Chrome 117, or StarOffice and OpenOffice.org. OK, these are both very imperfect comparisons, but although FLoC and Topics work in somewhat different ways, Topics is for all practical purposes just a fork that continues FLoC. They even treated it that way in the browser (at the time at least, no idea if it’s still so). https://en.wikipedia.org/wiki/Federated_Learning_of_Cohorts#... seems overall a fair enough portrayal. They simply rebranded the basic concept.
> 3. Topics is reducible to (implementable using) third-party cookies. While the proposal has issues and doesn’t resist tracking as well as Google claims (see below article), Ars’ implication that this is somehow making Chrome less privacy-preserving is patently false.
The first and last claims here are obvious nonsense. Third-party cookies only let you track stuff where your code runs, whereas the Topics API uses the entire browser history, so it’s not reducible to third-party cookies unless you mean something very different from me by that word. Ars’ implication is by no means patently false; as far as the current status is concerned, where they’ve added this and not removed third-party cookies, it’s patently true. In the longer term, it’s less clear, better in some ways and worse in others, but “patently false” is still an unreasonable characterisation.
> Third-party cookies only let you track stuff where your code runs, whereas the Topics API uses the entire browser history
This is false. Topics only allows ad trackers to see topics associated with sites they were embedded in. In this way, topics is reducible to TPC.
>whereas the Topics API uses the entire browser history
It doesn't use the full history. If a site is using the Topics API it will only get back topics that it has observed from sites in the last 3 epochs. For site X to observe a topic from site Y. Site Y must either:
* Be site X
* Embed site X in an iframe on the page with a special attribute on the iframe element
* Send a fetch request to site X with a special header and site X must respond with a special header
Your description claims that Google sends topics to site X only from history related to site X.
Which makes this useless from advertising point of view. Which also means that Google is using the whole history to come up with "rough tooics".
Let's see:
--- start quote ---
With Topics, your browser determines a handful of topics, like “Fitness” or “Travel & Transportation,” that represent your top interests for that week based on your browsing history.
https://blog.google/products/chrome/get-know-new-topics-api-...
The browser observes and records topics that appear to be of interest to the user, based on their browsing activity.
https://developer.chrome.com/blog/new-in-chrome-115/
With the Topics API, the browser observes and records topics that appear to be of interest to the user, based on their browsing activity. This information is recorded on the user's device.
https://developer.chrome.com/docs/privacy-sandbox/topics/ove...
--- end quote ---
From your last link:
> API callers only receive topics they've observed
> A design goal of the Topics API is to enable interest-based advertising without sharing information with more entities than is currently possible with third-party cookies. The Topics API is designed so topics can only be returned for API callers that have already observed them, within a limited timeframe. An API caller is said to have observed a topic for a user if it has called the document.browsingTopics() method in code included on a site that the Topics API has mapped to that topic.
6 replies →
The top 5 topics for an epoch is calculated using all of your browsing history in that epoch.
A site observing a topic in the last 3 epochs unlocks the ability for document.browsingTopics() to return that topic from your top 5.
Every epoch each site has a 95% chance to be assigned 1 topic out of your top 5 topics and a 5% chance that it is assigned a random topic. When browsingTopics is called it gets the topics it was assigned for the last 3 epochs. Real topics are not returned if the site did not observe that topic in the last 3 epochs as mentioned in the previous paragraph.
It's on a per-tracker basis. For an ad provider to see a given topic it must have been embedded in a site with that topic. In GP's comment "site X" is referring the site being embedded, not the top-level site. Again, this is reducible to third-party cookies.