This was going to be the compromise that would allow Chrome to have a path towards deprecating third-party cookies without massively decreasing its ad revenue, but they've walked away even from that: https://privacysandbox.com/news/privacy-sandbox-update/
> Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing, and they’d be able to adjust that choice at any time. We're discussing this new path with regulators, and will engage with the industry as we roll this out... We'll continue to make the Privacy Sandbox APIs available and invest in them to further improve privacy and utility.
There are numerous ways that the Topics API could leak sensitive information (say, for instance, increased values for a set of topics statistically related to life events with legal/health consequences) - I'm glad that opposition is being highlighted.
If ever there was an antitrust situation it is Google and Chromium.
(a) Widespread use of the engine which means its behaviour is what is largely defining the rules of the web today.
(b) It is driven by the financial interests of Google, specifically their Ads division. For example: Google recklessly adds every API under the sun even though they know they are being abused for fingerprinting. And they have long lived first party cookies which are used for re-targeting, attribution and conversion tracking. Both of which have major impacts to ad revenue.
To be clear, it's actually everyone else that benefits from this sort of API. Regulators (eg CMA) are the ones stopping Google from removing third party cookie support from Chrome without a suitable replacement. The world is more complex than what you can see at a glance.
How is this different from FLoC? My understanding was that Google came out with FLoC to solve this problem, but then scrapped it when it became clear that no one wanted it except Google.
Getting rid of third party cookies will not be an issue for advertisers.
They simply have websites use first party cookies, send the data server side to data harvesters, tie it all to a global user profile using either identifiers from the website or from fingerprinting and then serve targeted ads.
i.e. Conversions API (Meta), Server Side GTM (Google)
I would be surprised if most advertisers would even be interested in this topic API.
Websites are moving towards providing md5/sha1/sha256 hashes of your normalized email (stripping the + from gmail) or phone number to advertisers.
A basically permanent ID. Unified ID2 is one version of this.
The 3rd party cookie ban and heavy pushback against alternative solutions suggested by Google just pushed advertisers into going an even worse route privacy wise.
Yes and this was pointed out on pretty much every thread about this, but it was always drowned out by the extremists. Most people on HN are extremists in this case.
> They simply have websites use first party cookies, send the data server side to data harvesters, tie it all to a global user profile using either identifiers from the website or from fingerprinting and then serve targeted ads.
This is legally tricky because GDPR and similar legislation requires getting explicit consent from users for this to happen. Currently this is not very well enforced (imo) but it seems likely that enforcement will become increasingly stringent in years to come.
> They simply have websites use first party cookies, send the data server side to data harvesters, tie it all to a global user profile using either identifiers from the website or from fingerprinting and then serve targeted ads.
That honestly sounds like circumvention of unauthorized access. That's just breaking software protections.
No. Let’s be clear: Google absolutely could have continued in removing third party cookies. They’d be doing what Apple and Mozilla already do today, after all. The problem is that Google’s alternatives that still allow tracking by ad providers have run afoul of regulators and Google isn’t prepared to lose that ad revenue.
Hypothetically, what could the modern web look like if instead of inferring user attributes we let users specify those?
E.g.; I tend to want recipes by French authors. I have a profile set up in my browser to search in French, prefer French results, and when localization is applicable to retrieve results written in France. Switching to this profile is a button-click and automagically affects what all websites I visit believe out my personna.
E.g.; In that same example, even ad-tech presumably benefits from believing my ruse. If I'm in a mood to read French recipes in French, an ad for a US Football game is probably not going to land very well. Perhaps some company could do better by targeting based on both who I am and who I'm purporting to be (especially with respect to important life characteristics like log10(salary) and count(children)), but the temporary personna is by itself likely already better than any inferred characteristics at guiding targeted ads.
E.g.; I throw on a DIY personna. Instead of being inundated with (mostly fake) repair services when I ask for bike or device repair information, I find links to solid content like Sheldon Brown's blog and commercial links to informational content, DIY-focused parts and tools for sale, .... The web can still be a for-profit, sanitized entity while providing a vastly better experience for me the searcher and also the poor sucker paying for "bike repair shop" ads on my searches which could never possibly convert for that concept.
The irony of telling people how to use something you're opposed to...
It's clear that mainstream browsers have become the exact opposite of user agents. Unfortunately I don't see an easy solution to that problem beyond educating web developers and users, to change course to avoid all this hostile complexity, and possibly creating more alternative browsers that explicitly don't support things like this (or will lie about it to preserve the interests of the user: https://news.ycombinator.com/item?id=36935843 )
> The irony of telling people how to use something you're opposed to...
To a certain extent, I expect people to do exactly that as part of an argument in good faith, especially in a technical context. If you can't explain to me how something works, why should I trust your feedback, be it positive or negative?
I don't care how something works if I'm against the purpose. The same "but we should have a technical argument" BS was used by proponents of WEI, and thankfully most people saw through it.
I think you misunderstood me. I'm not trying to move the goalposts by suggesting "we should have a technical argument". Discussing whether the feature should even exist is itself a technical discussion.
Let's use WEI as an example. You're clear enough in your opinion: you think it shouldn't exist. Why, though? What does it do that you object to? Do you understand how it works well enough to be sure it does the bad thing you think it does? Imagine I'm interested in the discussion, but haven't formed an opinion. I just have Google on one side talking about guaranteeing the integrity of the browser environment somehow, and you saying "DO NOT WANT" on the other. You'll have a much easier time convincing me of your point of view if you can simply show me that you actually understand WEI, and if you can make me understand it too.
I don't care how it works. When the goal is the problem, the method is irrelevant. WEI is a problem because it takes away user's freedom to interact with sites using the software they want. It doesn't matter at all how it accomplishes that goal.
> It's a documentation site. You want it to pretend the API doesn't exist, or what?
MDN is a documentation site for web technologies.
In order for something to become a web standard, it needs two independent implementations. If Google can’t build consensus or convince anybody outside of Google to implement it, it’s not a web technology, it’s just some Google API that Google built for Google’s needs.
This is out of scope for a site dedicated to web technologies. This is like expecting them to document Android APIs.
It's a proposal for a web technology. Every web technology starts as a proposal, even if nobody but a single vendor implements it. MDN includes documentation for serious proposals at all stages, regardless of the standardization process.
In fact, MDN includes non-standardized APIs as well. Browser-specific interfaces are included, because it turns out that if you only document the APIs that went through the standardization process and not the ones that actually exist, it makes for a bad documentation site.
It’s a proposal that was rejected by everybody who isn’t Google. It isn’t going to be part of the web platform. It has exited the standardisation process. It’s at stage “never”. It belongs on MDN about as much as JSSS does.
That doesn't change anything. Whether or not it ever ships doesn't mean it shouldn't be documented. There's zero cost to documenting it. Just because you don't like it and it didn't make it past the proposal stage doesn't mean it shouldn't be on MDN. That's not how MDN works.
Mozilla started working on a similar API with Facebook back when Google announced FLOC. They are most likely more opposed to the bad press FLOC got than they are to the idea itself.
> They are most likely more opposed to the bad press FLOC got than they are to the idea itself.
I'm not well informed of how Mozilla is run, but isn't it just a business? Does it have any consistent values? I would assume that all decisions made by Mozilla are a balancing act between money and pr.
It's Mozilla's documentation site. Firefox doesn't have the API. It has no obligation to even mention its existence. The only thing that documentation is doing is helping Chrome.
If I'm interpreting you correctly, please explain how you got from "mozilla.org documents this API" to "firefox is not acting as a user agent".
>MDN Web Docs content is maintained by Mozilla, Google employees, and volunteers (community of developers and technical writers). It also contains content contributed by Microsoft, Google, and Samsung who, in 2017, announced they would shut down their own web documentation projects and move all their documentation to MDN Web Docs
I kind of want to emphasize "Mozilla's" too. It's not firefox documentation, it's web documentation.
> I'm speaking about browsers in general.
But you're specifically including firefox because of this page, right? That's a hell of extrapolation to make from them "helping" chrome by writing/hosting an article.
> The only thing that documentation is doing is helping Chrome.
In what way is documenting the API helping Google? There's a big banner right at the top of the page saying Firefox and Safari aren't going to implement it.
Should Mozilla also not document -webkit- prefixed CSS properties?
If it makes you feel any better, this sort of nihilist puritanism, combined with the people who actually sell data complaining to the EU it's "anticompetitive" they can't track me via 3P cookies, means this is DoA. And users are the only ones worse for it, modulo Google's sunk cost in investment in trying to do something better.
This looks like anti-privacy with extra steps. This breaks the disconnection that iframe provides. Kind of like turning iframe into a detective. Were you interested in tennis on the night of January 3rd?
I haven't read the spec entirely, but couldn't "infer" mean "check with a compressed list of millions of urls already categorized offline and cached on disk" ?
I'm responding to questions on whether or not this could work - "Isn't this just naive and may not actually produce useful results".
It could work in the degenerated case of just having a giant dictionary of the top hundred million websites and all their topics, so it stands to reason it could work with "ai" too. Each region's browsing behavior is so "head heavy" I would think you'd rarely need to interpolate to see things that weren't in the "training set" of offline categorized sites.
Yes, it is a classifier doing drum roll please topic modelling on the content you are looking at. But it runs the model locally so your privacy is totally preserved... right? Not that I consented to my CPU/GPU cycles being used against me in this way though.
Is there any way I can find where this topic information is stored? I presume it's a SQLite database in the profile folder, like the cookies and history.
I don’t know about on disk, but you can look at it in Setting > Privacy and Security > Ad Privacy > Ad Topics.
When I look at mine, Ad Topics always been very generic and boring. “Site-suggested ads” seems more worrisome because some domain names are very specific.
Do you mean in Chrome? You can disable it from the settings. There should have been a prompt to review the features' settings when it was first introduced.
I seriously do not understand why people use Google Chrome and other Chromium derivatives.
It's one thing that my non-tech sphere friends do, but I see so many people at work just defaulting to using Google Chrome, and I frankly just cannot fathom it.
Like, FFS, is browser sync that useful? In 30+ years using the web on a bunch of different computers, I have not once ever been like "ooooh I wish I had the 35+ tabs I had open on my work computer on my personal one".
the answer is simple, they don't care that much about privacy, despite claiming so.
And for the rest of us devs who actually care, we're just lazy and continue using the work browser for private purposes. Why Chrome as work browser? Because most users use it.
> Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing, and they’d be able to adjust that choice at any time. We're discussing this new path with regulators, and will engage with the industry as we roll this out... We'll continue to make the Privacy Sandbox APIs available and invest in them to further improve privacy and utility.
Discussion here: https://news.ycombinator.com/item?id=41038586
There are numerous ways that the Topics API could leak sensitive information (say, for instance, increased values for a set of topics statistically related to life events with legal/health consequences) - I'm glad that opposition is being highlighted.
Apple's opposition comments are also worth reviewing: https://github.com/WebKit/standards-positions/issues/111