+100 it was only ever a political decision and had no bearing on reality

Closing as having a pull request, see #36855 . In case if that gets not accepted we have to re-open the issue.

It was a clear, necessary and correct statement to add the unFloc feature also in Joomla. It wasn't "premature and unwarranted".

@ReLater No, it was never necessary, it was never correct, it was never a security feature and — the best part! — it never actually worked.

The Google FLoC EXPERIMENT was only run against SOME North Americans. It was an experiment, meaning that it only run on a very subset of Chrome installations. It was proposed as a W3C standard but by the time the code experiment was live it was already dead in the water — the only way Google moved forward with it was to see if on-device processing was possible (they had killed the “federated” part before releasing it).

These are easily verifiable facts.

Moreover, Joomla came late to this party, a week after WordPress already had this discussion in public, already had these facts laid out and made the correct decision to not take action until such time as FLoC actually became a standard (which, of course, everyone with half a working braincell had figured out would never happen).

This is also an easily verifiable fact.

Should we also mention that FLoC would do sod all on the vast majority of sites? It would ONLY affect sites running ads and only if the ad server supported FLoC. Even that wasn't a given since the only source of information about the HTTP header was a post on HackerNews which pretty much admitted that its source was hearsay. That HTTP header was never officially supported by Google.

This is also an easily verifiable fact.

These facts were known on April 23rd, when I made my comment. They were known before the issue in Joomla's GutHub tracker was opened! That's also an easily verifiable fact in and of itself!

If you want to put faith in hearsay i.e. what Google engineers wrote in a private capacity, without expressing the company's official position, why not also trust them saying that should FLoC become generally available it would be possible to turn it off through the browser options, meaning that any feature to block FLoC in Joomla would be so very much premature and utterly unwarranted.

Let me sum it up

Implementing a feature which MIGHT block what was clearly designed to be a sort-lived experiment with zero traction in the web standards authority (W3C) and which was only available to a tiny subset of a minority of our CMS' users, falsely touting it as a “security” feature and putting it in the Global Configuration instead of an optional plugin, was worse than premature and unwarranted, it was JUST. PLAIN. BONKERS.

So why was it added?

The reason this feature was added was a shoddy attempt at scoring political points with privacy nuts — not privacy-conscious users and privacy advocates, I am talking about the veritable nutcases, the conspiracy theorists, the people who belong in an asylum and not in the real world.

I am all for privacy and security — hell, that's what I do for a living. I did not object to this feature because of who contributed it. I objected to this feature because it was objectively premature and unwarranted.

I will also say that I, myself, thought it might be a good idea two days before the Joomla issue was opened. As I was researching the topic I quickly realised that addressing FLoC is premature and unwarranted. The original HackerNews article was very selective in the information it provided, making it appear like Google was pushing FLoC in general availability worldwide and that the federation feature was shipped and impossible to disable. Not a single one of these assertions was ever true. FLoC was an experiment. It was only available to a tiny sliver or Northern Americans. Federation was nixed before it even shipped. The post was written by a privacy nut. All their false claims were debunked by... wait for it... privacy advocates 😱

Right now there are competing proposals from Google and Mozilla about a target ad framework, neither of which is likely to be accepted by W3C. They still have not ironed out the privacy and security issues arising from the browser happily divulging interest cohorts left and right. Even Google itself has qualms over whether some interests in some regions might be a physical security threat (think about the implications of a repressive theocracy's site learning that User X has an interest in gay dating — that could very well be a death sentence!).

Considering that the W3C has not figured out a way to provide tools for privacy-respecting, secure ad targeting which are not worse than the current rolling Dumpster fire state of affairs it is extremely premature for an Open Source CMS like Joomla with a quick feature turnaround time to even contemplate about what to do should such a standard emerge. If it emerges we have to consider whether the user is in control of it through their device / browser, if it's feasible for us to block it in a way that puts the site owner and/or the site visitor in control and only then contemplate a code implementation. I mean, even with the insanely flawed FLoC experiment, for some users it would be a lesser privacy and security threat than contemporary ad targeting code. Who are we to rob them of that option?

This really should be removed

@joomlaphp It's already removed 😉