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.
>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.
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.
> 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.
This doesn't say that topics only come from the same website. It only says that if a website has "observed" any of the thousand or so topics, one will be provided to that site based on user activity.
Edit. Literally last link:
> Map browser activity to topics of interest. With the current design of the Topics API, topics are inferred from the hostnames of pages the user visits.
The original claim was that Topics API doesn't use the whole browser history, and that sites inly get topics for that site.
Whereas the description clearly states that topics are derived from the entire browsing history, and they will get topics derived from the test of the history because while coarse, there are still a bunch of them.
A site with a narrow site like a site on fresh-water aquatic plants will probably only get a handful of topics. What will Amazon get? Or Google for that matter? Or a news site? Given that they are likely to "observe" every single topic?
The original discussion was comparing the Topics API to third party cookies.
The way that the Topics API works is that a website that could have set a third party cookie will instead be able to observe a topic, and will then be able to get that topic in the future.
The comment I responded to claimed that Topics API doesn't use the full history and that a site X won't get topics derived for site Y: https://news.ycombinator.com/item?id=37429447
That's true, or rather no site gets access to the full history, or to topics that are derrived from the full history, but only to that part of the history that it "observed".
> a site X won't get topics derived for site Y
Unless site Y allowed them to, which of course site Y can also do by allowing them to set a third party cookie.
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.
> 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.