> The Topics API enables interest-based advertising (IBA) without tracking the sites a user visits. 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.
> For example, the API might suggest the topic "Fiber & Textile Arts" for a user who visits the website knitting.example.
I know a lot of people don't like the Topics API and FLoC (which I believe is dead now, but was kind of the MVP for Topics) and I'm not saying it's perfect, but from everything I've read on it, it seems like a massive improvement over third party cookies.
Am I wrong in thinking this way?
I realize there are plenty of people out there who just don't want to be tracked at all, but I don't think that option was really ever on the table for Chrome users. To me this seems like a step in the right direction.
If there's anyone who can explain the downsides of this new API and has an alternative other than "don't track me" I would honestly love to hear it. I'm sure there are some, but I'm struggling to think of them.
Do you work at Google? The reason I ask is because I fail to understand how the premise of "topics" or "floc," or whatever you want to call it, benefits anyone other than Google shareholders and employees. Browsers don't need to be advertising machines, and the idea that somehow ads need to "work" or be "private enough" is a false premise that only exists because Google depends on tracking users so they can extract maximum prices from advertisers.
The problem is not that there's a "downside" to the feature - the problem is that it exists at all.
“Topics API or third-party cookies” kinda goes beyond being a false dichotomy to being a blatant lie. The conflict of interest demonstrates how Google is unfit as the custodian of a leading browser. This is a single-vendor thing to bolster their own interests and which they can only do because they’re a leading advertising company, and which no one else supports in any way.
Firefox and Safari have already stopped supporting third-party cookies, and nothing bad happened.
(There are a few cases here and there of legitimate systems breaking due to relying on third-party cookies for things like login, and these have broken in Firefox and Safari, but they’ll break in Chromium too when it kills off third-party cookies, and the Topics API is completely irrelevant to these cases, being exclusively about advertising interests, so these cases aren’t part of the “third-party cookies or Topics API” deceit.)
Note also how Apple and Mozilla have both taken negative positions on the Topics API: it’s extremely unlikely either’s browser engine will ever support it, making the falseness of the dichotomy even clearer.
Useful further reading, identifying various concrete problems with the Topics API (if “but why should it even exist at all?” wasn’t enough):
Why have either? What _user_ wants this? I really struggle to find people that want to be tracked, even anonymously, that have no ties to said tracking companies.
And surprising to many ordinary HN readers, it is actually better for Google to deprecate 3p cookie as early as possible since the digital ads market competes on finite budget and whenever something uncertain happens it almost always works in a way that benefits big, established players. Of course other small players definitely understand this and has approached to competition regulation entities so Google cannot simply get rid of 3rd party cookies and kick the ladder... Advertising is an extremely optimized business sector and its landscape is not that simple; no one is going to get everything they want.
The other answers seem to completely miss your point. You're not asking "is this good" you're asking " is it less worse than status quo".
I think it's a fair question.
From my non-expert point of view it's actually less bad, but I use Firefox, with unlock and some fingerprinting blockers so I'm certainly not the target demographic.
What I wish would be possible is to forbid websites to break functionality of 3rd party cookies are not enabled...
I cannot understand the problem in just showing ads based on the content of the website I am visiting. You don't need to spy on me to realise that I am interested in needlework if I am on a site called threadsandneedles.com
Meanwhile the ads that do track me are annoying as hell and frequently show shit I am not the least interested in (Facebook knows I work in IT, why my timeline isn't full of cool as hell gadgets I will never know).
> To me this seems like a step in the right direction
This implies that there are more steps in that direction.
Can you think of any follow-up steps that are in favor of the user? Or do you think it's more realistic that advertisers regain their former superpowers?
I don't mean to nitpick your phrasing, I'd like to understand if there's some long-term benefit to users that I don't see.
I actually think something like the Topics API could work - but with some pretty big changes.
Firstly, it's a "hell no" from me on my browser recording what I'm doing and insinuating my interests. At the very least, I'd want to be able to disable that.
Secondly, I want to be able to see the topics that are chosen.
Finally, I want to be able to edit/set these topics myself.
If you can edit/set these, what's the point in having any of this? If they want to know your interests they could just ask and accept no as a valid answer. The iOS changes proved that people do not want to be tracked, I think.
A few years ago, I worked for a company that helped retailers infer user intent. And you would not believe the lengths that they would go to to infer simple things like sex (for clothing sites with male and female sections). I kept saying, "Wouldn't it be great if, you know, we just asked people?" And everyone said, "Oh, no, people are never going to volunteer that. They want privacy!"
So, great, now we get a Topics API to help advertisers extract this info involuntarily.
But without a Shopping API or similar method of volunteering info that's actually useful and makes my browsing experience easier, I have to re-apply the same filters incessantly on every online shopping site I visit, even though I really don't care if anyone knows that I'm a Men's Large with a 36-inch waist.
Yeah you’re right - just ask the user. They can say no, or they can tell you what you want to know. I think companies know that most ppl don’t want to hand over info.
This current opaque adtech system coupled with dark pattern ‘options’ to appear like they care is insulting and arrogant.
So who decides which topics exist and which topics match to which websites? Will the browser send all websites you visit to Google and get back the list of topics?
So they created a new event so people can use JS to create "reading indicators which move as you scroll." You know what else can do that? Scroll bars. In the browser. That don't disappear. Those tell you how far you are in the document as well.
It's hard to rely on the scrollbar if the website either loads the article as you scroll (I think Ars Technica does this) or you know whether or not there's a comments section. Or sometimes there is a comments section but it doesn't load until you scroll it into view.
I find myself frequently jumping to the bottom of the article to see if the small scrollbar is due to the article length or a comments section.
Websites that are doing obviously wrong things shouldn't be used to justify another layer of bad features being added. There's never any justification for deferring loading of the rest of an article until you scroll. The images, maybe, but definitely not the text.
There are already JS solutions for scroll-based behaviors and styling (the actual scroll event, IntersectionObserver which performs better because it’s non-blocking and batched).
Scroll Timeline is a CSS-only solution. And it’s kind of a misnomer, it’s really a position-based styling mechanism that can be used without any scrolling at all[1].
At minimum, this API will allow existing functionality that relies on scroll position to perform better (first by integrating with the rest of the CSS-paint pipeline, next IIUC by offloading to GPU where possible), which itself is welcome. But it also unlocks a bunch of other styling possibilities that are either impossible without JS or rather brittle.
Fenced frames seem so over-engineered. Why not just add a `fenced` attribute to a regular `iframe` which we can toggle on or off? Looking at the Chromium source, the `fenced_frame.cc` implementation is almost literally copy-pasted from `iframe` anyway.
Fenced frames seem to break the 3rd party cookie isolation that has become standard in web browsers.
Sure, they put protections in place... But nothing stops the forums on shadysite.com putting a fenced frame to this34yearoldmalehasanipof1234andsessionidof7775.advertiser.com
I predict that this move is worth multiple billions to Googles advertising team...
In fairness, scroll bars must account for lots of non-content stuff on the page, like comments. A reading indicator can reflect where in the primary content the reader is.
> With a fenced frame, the publisher could display an ad which matches visitor interests, but the src and interest group will be known only to the advertiser in the frame. The publisher could not access this information.
I would like to have an LTS version of browser with no experimenting options where user is acknowledged that websites more complicated than HN will not run and show "update your browser" notification instead, but at least it has to be safe from 0day exploits.
Depending on your definition of "L" in "LTS," that sounds like Firefox ESR (Extended Support Release).
"Extended Support Release (ESR): receives major updates on average every 42 weeks with minor updates such as crash fixes, security fixes and policy updates as needed, but at least every four weeks."
I like that ScrollTimeline is coming, I hope to get rid of JS scroll listeners for good. Can't wait to use this in like 5 years when all browsers finally support it.
> The Topics API enables interest-based advertising (IBA) without tracking the sites a user visits. 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.
> For example, the API might suggest the topic "Fiber & Textile Arts" for a user who visits the website knitting.example.
Hmm.. That doesn't sound good.
I know a lot of people don't like the Topics API and FLoC (which I believe is dead now, but was kind of the MVP for Topics) and I'm not saying it's perfect, but from everything I've read on it, it seems like a massive improvement over third party cookies.
Am I wrong in thinking this way?
I realize there are plenty of people out there who just don't want to be tracked at all, but I don't think that option was really ever on the table for Chrome users. To me this seems like a step in the right direction.
If there's anyone who can explain the downsides of this new API and has an alternative other than "don't track me" I would honestly love to hear it. I'm sure there are some, but I'm struggling to think of them.
Do you work at Google? The reason I ask is because I fail to understand how the premise of "topics" or "floc," or whatever you want to call it, benefits anyone other than Google shareholders and employees. Browsers don't need to be advertising machines, and the idea that somehow ads need to "work" or be "private enough" is a false premise that only exists because Google depends on tracking users so they can extract maximum prices from advertisers.
The problem is not that there's a "downside" to the feature - the problem is that it exists at all.
15 replies →
“Topics API or third-party cookies” kinda goes beyond being a false dichotomy to being a blatant lie. The conflict of interest demonstrates how Google is unfit as the custodian of a leading browser. This is a single-vendor thing to bolster their own interests and which they can only do because they’re a leading advertising company, and which no one else supports in any way.
Firefox and Safari have already stopped supporting third-party cookies, and nothing bad happened.
(There are a few cases here and there of legitimate systems breaking due to relying on third-party cookies for things like login, and these have broken in Firefox and Safari, but they’ll break in Chromium too when it kills off third-party cookies, and the Topics API is completely irrelevant to these cases, being exclusively about advertising interests, so these cases aren’t part of the “third-party cookies or Topics API” deceit.)
Note also how Apple and Mozilla have both taken negative positions on the Topics API: it’s extremely unlikely either’s browser engine will ever support it, making the falseness of the dichotomy even clearer.
Useful further reading, identifying various concrete problems with the Topics API (if “but why should it even exist at all?” wasn’t enough):
https://github.com/WebKit/standards-positions/issues/111
https://github.com/mozilla/standards-positions/issues/622
https://github.com/w3ctag/design-reviews/issues/726
5 replies →
Why have either? What _user_ wants this? I really struggle to find people that want to be tracked, even anonymously, that have no ties to said tracking companies.
18 replies →
> If there's anyone who can explain the downsides of this new API and has an alternative other than "don't track me" I would honestly love to hear it.
“Don’t track me” should be sufficient.
And surprising to many ordinary HN readers, it is actually better for Google to deprecate 3p cookie as early as possible since the digital ads market competes on finite budget and whenever something uncertain happens it almost always works in a way that benefits big, established players. Of course other small players definitely understand this and has approached to competition regulation entities so Google cannot simply get rid of 3rd party cookies and kick the ladder... Advertising is an extremely optimized business sector and its landscape is not that simple; no one is going to get everything they want.
The other answers seem to completely miss your point. You're not asking "is this good" you're asking " is it less worse than status quo".
I think it's a fair question.
From my non-expert point of view it's actually less bad, but I use Firefox, with unlock and some fingerprinting blockers so I'm certainly not the target demographic.
What I wish would be possible is to forbid websites to break functionality of 3rd party cookies are not enabled...
I cannot understand the problem in just showing ads based on the content of the website I am visiting. You don't need to spy on me to realise that I am interested in needlework if I am on a site called threadsandneedles.com
Meanwhile the ads that do track me are annoying as hell and frequently show shit I am not the least interested in (Facebook knows I work in IT, why my timeline isn't full of cool as hell gadgets I will never know).
> To me this seems like a step in the right direction
This implies that there are more steps in that direction.
Can you think of any follow-up steps that are in favor of the user? Or do you think it's more realistic that advertisers regain their former superpowers?
I don't mean to nitpick your phrasing, I'd like to understand if there's some long-term benefit to users that I don't see.
The alternative is context-sensitive ads based on surrounding context.
> If there's anyone who can explain the downsides of this new API and has an alternative other than "don't track me"
Exactly what’s wrong with that?
I actually think something like the Topics API could work - but with some pretty big changes.
Firstly, it's a "hell no" from me on my browser recording what I'm doing and insinuating my interests. At the very least, I'd want to be able to disable that.
Secondly, I want to be able to see the topics that are chosen.
Finally, I want to be able to edit/set these topics myself.
If you can edit/set these, what's the point in having any of this? If they want to know your interests they could just ask and accept no as a valid answer. The iOS changes proved that people do not want to be tracked, I think.
1 reply →
A few years ago, I worked for a company that helped retailers infer user intent. And you would not believe the lengths that they would go to to infer simple things like sex (for clothing sites with male and female sections). I kept saying, "Wouldn't it be great if, you know, we just asked people?" And everyone said, "Oh, no, people are never going to volunteer that. They want privacy!"
So, great, now we get a Topics API to help advertisers extract this info involuntarily.
But without a Shopping API or similar method of volunteering info that's actually useful and makes my browsing experience easier, I have to re-apply the same filters incessantly on every online shopping site I visit, even though I really don't care if anyone knows that I'm a Men's Large with a 36-inch waist.
Yeah you’re right - just ask the user. They can say no, or they can tell you what you want to know. I think companies know that most ppl don’t want to hand over info.
This current opaque adtech system coupled with dark pattern ‘options’ to appear like they care is insulting and arrogant.
Yeah I want to know what my topics are and when they change, and if I can disable or fudge my topics.
Not sure if it landed yet, but being able to edit/disable individual topics was an announced feature.
FWIW most ad networks already let you do this. Here's google's https://myadcenter.google.com/home
3 replies →
There is an internal page chrome://topics-internals where you can see the topics but I don't think you can fudge them
https://developer.chrome.com/docs/privacy-sandbox/topics/#ob...
1 reply →
You'd figure it would be a pretty easy thing for a fork to just... not implement?
I'll assume they won't be so polite as to allow extension to disable this "feature"
1 reply →
Dunno, seems useful.
Build a zero effort dmoz by visiting individual sites with a clean headless browser and then querying the topic API.
It's like Google is trying to give the government evidence of browser / ad vendor bundling effects
So who decides which topics exist and which topics match to which websites? Will the browser send all websites you visit to Google and get back the list of topics?
At this point, I wouldn't be surprised if they announce the "User-Agent" request header will be "Google-Agent" going forward.
I guess I don't understand how it is different or better from Google's perspective for its users.
Is the main benefit you don't know the exact site you visited but the type of site and basically all the contents or "topics" of it?
Not looking to flame. Genuinely looking for just the rundown explanation // privacy benefits // etc..
Please elaborate? It seems a terrific idea.
Yeah. That's sounds icky and gross.
So they created a new event so people can use JS to create "reading indicators which move as you scroll." You know what else can do that? Scroll bars. In the browser. That don't disappear. Those tell you how far you are in the document as well.
It's hard to rely on the scrollbar if the website either loads the article as you scroll (I think Ars Technica does this) or you know whether or not there's a comments section. Or sometimes there is a comments section but it doesn't load until you scroll it into view.
I find myself frequently jumping to the bottom of the article to see if the small scrollbar is due to the article length or a comments section.
Websites that are doing obviously wrong things shouldn't be used to justify another layer of bad features being added. There's never any justification for deferring loading of the rest of an article until you scroll. The images, maybe, but definitely not the text.
I don’t think the new scroll timeline fixes the lazy loading issue.
There are already JS solutions for scroll-based behaviors and styling (the actual scroll event, IntersectionObserver which performs better because it’s non-blocking and batched).
Scroll Timeline is a CSS-only solution. And it’s kind of a misnomer, it’s really a position-based styling mechanism that can be used without any scrolling at all[1].
At minimum, this API will allow existing functionality that relies on scroll position to perform better (first by integrating with the rest of the CSS-paint pipeline, next IIUC by offloading to GPU where possible), which itself is welcome. But it also unlocks a bunch of other styling possibilities that are either impossible without JS or rather brittle.
1: https://kizu.dev/position-driven-styles/
Fenced frames seem so over-engineered. Why not just add a `fenced` attribute to a regular `iframe` which we can toggle on or off? Looking at the Chromium source, the `fenced_frame.cc` implementation is almost literally copy-pasted from `iframe` anyway.
> Fenced Frames
Fenced frames seem to break the 3rd party cookie isolation that has become standard in web browsers.
Sure, they put protections in place... But nothing stops the forums on shadysite.com putting a fenced frame to this34yearoldmalehasanipof1234andsessionidof7775.advertiser.com
I predict that this move is worth multiple billions to Googles advertising team...
That plus "topics" makes for another great day to switch to Firefox or Safari.
So it's a backdoor for advertisers. This explained why they couldn't just extend the iframe. Should we call them adframes instead?
> For example you can create reading indicators which move as you scroll:
You know, scroll bars used to do that. Why are they not shown, or if shown extremely thin, on mobile devices?
In fairness, scroll bars must account for lots of non-content stuff on the page, like comments. A reading indicator can reflect where in the primary content the reader is.
Reading indicator can also distract and drive the reader crazy, especially when it is perpendicular to the scroll direction.
> Fenced frames
Okay, seems cool, but....why?
> With a fenced frame, the publisher could display an ad which matches visitor interests, but the src and interest group will be known only to the advertiser in the frame. The publisher could not access this information.
Ah, okay there we go.
These scroll-based animations are a plague. Just let scroll be scroll and show the whole image when you get to it
I would like to have an LTS version of browser with no experimenting options where user is acknowledged that websites more complicated than HN will not run and show "update your browser" notification instead, but at least it has to be safe from 0day exploits.
Depending on your definition of "L" in "LTS," that sounds like Firefox ESR (Extended Support Release).
"Extended Support Release (ESR): receives major updates on average every 42 weeks with minor updates such as crash fixes, security fixes and policy updates as needed, but at least every four weeks."
https://www.mozilla.org/en-US/firefox/all/#product-desktop-e...
Anyone know if fenced frames honor the No frame header? No reason they should now, right?
How will I be able to disable this? If it’s not possible, I won’t be upgrading.
I'm not sure. There could be a setting or maybe something in chrome://flags, but purely on principle I'm voting with my feet and switching to Firefox.
I like that ScrollTimeline is coming, I hope to get rid of JS scroll listeners for good. Can't wait to use this in like 5 years when all browsers finally support it.
I find the shared storage to be naively useful to share info between sites. But... You know, that will never be possible.
When does webgpu come for Linux?
As per Khronos meeting yesterday, really soon now.
So are the priorities of MountainView for desktop Linux, it is literally the last platform on Chrome roadmap support for WebGPU.
Are they adding more proprietary APIs?