We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

In Joomla 4 this should just be part of https://docs.joomla.org/J4.x:Http_Header_Management

Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

Should we also be putting this in htaccess.txt like the other headers like no-sniff? This would then apply the header globally and not only on PHP requests through the app.

"Google is introducing a replacement..."

Should the language be written time independently, so that in a decade it is still true? Maybe something like "In 2021, Google introduced..."

We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

In Joomla 4 this should just be part of docs.joomla.org/J4.x:Http_Header_Management

Agreed, we are just still discussing about that. We definitely don't want the above special case to live on in J4.

Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

Should we also be putting this in htaccess.txt like the other headers like no-sniff? This would then apply the header globally and not only on PHP requests through the app.

Maybe, however since most people don't update their htaccess on a Joomla update, we can't rely on this alone. Be my guest to add this header to the htaccess.

"Google is introducing a replacement..."

Should the language be written time independently, so that in a decade it is still true? Maybe something like "In 2021, Google introduced..."

I'm happy to accept a changed text PR to this branch.

we can't rely on this alone

Agreed, but the htaccess is still the right place for this also to be, over and above this PR. Just thought you might like to add it here for completeness.

I'm happy to accept a changed text PR to this branch.

haha that's @brianteeman domain :) I only speak crap.

Maybe, however since most people don't update their htaccess on a Joomla update, we can't rely on this alone. Be my guest to add this header to the htaccess.

Also need to check if .htaccess has this header, and Joomla outputs this header, do they resolve to a single header, or to two separate duplicated headers in the response - need to test that first.

Such a shame that the project doesn't take the use of cookies as seriously

Maybe, however since most people don't update their htaccess on a Joomla update, we can't rely on this alone. Be my guest to add this header to the htaccess.

Also need to check if .htaccess has this header, and Joomla outputs this header, do they resolve to a single header, or to two separate duplicated headers in the response - need to test that first.

Header has been set in htaccess.txt as well. Testing on my system only showed one header to be sent.

Update SQL scripts for PostgreSQL and for MS SQL Server/SQL Azure are missing.

Have been added. Sorry, it was late yesterday...

Such a shame that the project doesn't take the use of cookies as seriously

We try to improve: https://docs.joomla.org/GSoC_2021_Project_Ideas#Cookies_management

Since J4 has already the system_httpheader and @zero-24 already did the backport for J3 https://github.com/zero-24/plg_system_httpheader why don't you merge that to J3 (assuming that @zero-24 has no objections)?

Was consideration given to implement this as a standalone Plugin instead of "yet another" configuration option?

Was consideration given to the Post Installation message, to have "condition" for showing only if not enabled in global config and "a one click action" to implement the change like the 2FA and the Load Balancer change recently?

Since J4 has already the system_httpheader and @zero-24 already did the backport for J3 zero-24/plg_system_httpheader why don't you merge that to J3 (assuming that @zero-24 has no objections)?

Was consideration given to implement this as a standalone Plugin instead of "yet another" configuration option?

It was decided to keep the implementation minimal and to not use a separate plugin.

Was consideration given to the Post Installation message, to have "condition" for showing only if not enabled in global config and "a one click action" to implement the change like the 2FA and the Load Balancer change recently?

This feature is enabled by default, so people would need to disable it actively. In that case they can also click away the post install message.

We consider this a security issue and thus will roll out countermeasures

This has nothing to do with security, add it in J4 (default off), but don't force this in J3 in the name of security. At best this is a privacy concern (in the browser).

I see that Joomla is trying to not fall behind WP but please note that WP is NOT including this feature in its code, despite what the tech press misguidedly reported...

Moreover, this is not a definite security or privacy issue. Please do read https://twitter.com/Log3overLog2/status/1384337637763387394 for the whole story. In short, FLoC is only a concern if you include JavaScript which explicitly requests the FLoC cohort. Moreover, FLoC is currently an experiment, not a final implementation. In the few Chrome browsers this experiment is enabled — notably none in the EU, where the author of this PR lives — this is currently an opt-out feature just because it's the only way to run an experiment of a technology nobody has heard about before. Google seems to indicate that the final implementation is very likely to be opt-in, not opt-out, or at the very least provide a user warning the same way that asking for location data does. It is, in fact, extremely likely to be so because of GDRP and that's probably why the opt-out format experiment does not run in browsers of EU residents.

Further to that, this has NOTHING AT ALL to do with security. Your site can't be hacked with FLoC. Maybe — MAYBE — it will have to do with privacy IF AND ONLY IF the final implementation of FLoC is opt-out instead of opt-in. Marking it as a security concern dilutes the importance of fixing real security issues and projects the wrong message to users. If we label speculative, non-security issues as "SECURITY" the users are trained to ignore any security fix as superficial and unimportant, undermining their safety in the long term.

On top of that, sending a Permissions-Policy to disable FLoC doesn't mean that the user will magically no longer be tracked. In fact, it's possible that instead of being assigned into a cohort of at least 1000 users he will be otherwise tracked and placed in a finer grained cohort using a different set of tracking technologies including but not limited to ISP detection, IP geolocation, per-user subdomain pinging and so on. FLoC was actually designed to strengthen the privacy by making cohorts large enough so as not to allow individual tracking and deanonymisation. Whether we trust Google to do that is a largely philosophical question, not a technical one. From a technical perspective using the Permissions-Policy might actually prove counter-productive to the stated goal of protecting the user's privacy.

It is also worth noting that FLoC is only ever enabled if you include JavaScript in your page which uses FLoC (either directly on the page or via an IFRAME). This means that unless you are using analytics, ads or similar technology which uses FLoC-enabled JavaScript there is no placement in a cohort. Pretending that merely using Chrome on any site is magically destroying your privacy is misguided at best.

Based on this, there is no real benefit in including this in Joomla, let alone as a feature enabled by default. We are not protecting anyone from anything, especially the site owner i.e. it's not a "security" feature. What this feature does is probably disable FLoC if you are using third party ads, analytics etc on your site. Whether it will succeed depends entirely on the implementation. If a third party ad is included in your site via an IFRAME it's easy for it to add the allow="interest-cohort" in the attribute, nullifying this "protection". It would only work if the FLoC-enabled third-party JS only ever runs in the main page context on your site. Even then, whether it would be something that actually protects your users instead of enabling more tracking for them is something to be determined. Not to mention that we still do not know if Chrome will make it opt-in or display a warning before interest cohorts are used, especially in jurisdictions with strict personally identifiable information legislation.

In short, this PR jumps the shark by a freaking mile.

Finally, the implementation as it stands right now is completely wrong and breaks sites. It replaces the Permissions-Policy header instead of amending it. People who use plugins to set the Permissions-Policy for legal compliance, privacy or security reasons will be very surprised to see that their Permissions-Policy is overwritten and replaced with a BS non-fix of a speculative issue. So, while nothing (or at the very least nothing of importance) is fixed something of actual importance is broken for them! A better way to do it is more like along these lines (from a PR in Admin Tools Professional I have not merged yet for the reasons stated above):

	public function onAfterRender_disableFLoC()
	{
		// Get all headers
		$headers = $this->app->getHeaders();

		// Find the Permissions-Policy header's contents
		$headerContent = array_reduce($headers, function (?string $carry, array $headerDefinition) {
			if (strtolower($headerDefinition['name'] ?? '') === 'permissions-policy')
			{
				$carry = ($headerDefinition['value'] ?? '') ?: $carry;
			}
		}, '');

		$headerContent = trim($headerContent ?? '');

		// If the content is empty, append our special interest-cohort permissions
		if (empty($headerContent))
		{
			$headerContent = 'interest-cohort=()';
		}
		// If it's not empty and doesn't have an interest-cohort permissions add one
		elseif (stripos($headerContent, 'interest-cohort') === false)
		{
			$headerContent .= ',interest-cohort=()';
		}

		// Separate into separate permissions and replace any existing interest-cohort permissions with our special one.
		$permissions = array_map(function ($permission) {
			$permission = trim($permission ?? '');

			if (stripos($permission, 'interest-cohort') !== 0) {
				return $permission;
			}

			return 'interest-cohort=()';
		}, explode(',', $headerContent));

		// Remove empty permissions which would make our header invalid
		$permissions = array_filter($permissions, function ($x) {
			return !empty($x);
		});

		// Recombine everything into one big string separated by semicolons
		$headerContent = implode(';', $permissions);

		// Set the header in the application's response.
		$this->app->setHeader('Permissions-Policy', $headerContent, true);
	}

While this won't overwrite a permissions policy set by a plugin — including Joomla 4's core feature — it's still mostly window dressing because it can and will be overwritten by .htaccess or equivalent server-level code if it sets the Permissions-Policy header and can and will be overwritten by IFRAME attributes. As we say in Greece, this is very much like drilling holes in the water...

It's important to get all the facts straight before jumping the gun and implementing something under a false security banner, even more so when the implementation is plain bad code that breaks another core feature.

I believe (but may be wrong) that the only reason it is tagged as security is because thats what wordpress did. However they only did that so that they could apply the change outside of their normal release procedure.

For me, Google and others leveraging my privacy through the back door is a security issue. Preparing for such an issue early on is the right way to go and a good signal. The counter-reactions aren't just coming from WordPress. Google statements and maybe-promises as arguments against such a preparation are not to be considered serious.

@ReLater so dont enable anything on your site that implements FLoC or similar. This doesnt just appear on your site without you doing something

https://github.blog/changelog/2021-04-27-github-pages-permissions-policy-interest-cohort-header-added-to-all-pages-sites/

Interesting that GitHub would force this on its users pages - but not on its own site, or the GitHub.com service entirely. :)

Since github enabled this "feature" chrome browser 90.0.4430.93 (Official Build) (64-bit) issues the following error

Error with Permissions-Policy header: Unrecognized feature: 'interest-cohort'.

Symfony just implemented it https://twitter.com/fabpot/status/1387777376898228232

Fabien Potencier @fabpot #Google FLoC is now out on symfony.com. All other #Symfony websites will follow soon.

and in Symfony Framework Core:

PR opt-out from Google FLoC by default symfony/symfony#40989

So I have been testing this today.

After I suggested this be tested with the .htaccess as well, @Hackwar states he tested .htaccess headers - my findings directly contradict his.

My custom set up for testing this today was:

• Apache
• a2enmod headers
• PHP 7.3

IF you have .htaccess line (which is enabled by default if you use the Joomla provided htaccess) and you have block_floc enabled (which is enabled by default), and IF you are running apache with Headers module enabled, then you get a double header value which is not valid

Permissions-Policy: interest-cohort=(), interest-cohort=()

If my .htaccess already contains a "Permissions-Policy" header (Which is very possible for sites that have been using Feature Policy headers promoted for years by securityheaders.com) - for example this header in .htaccess:

Header always set Permissions-Policy "accelerometer=(), ambient-light-sensor=(), autoplay=(self), camera=(), encrypted-media=(), fullscreen=(self), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(self), picture-in-picture=(), speaker=(), sync-xhr=(), usb=(), vr=()"

And then I upgrade to Joomla 3.x that contains FLoC enabled by default, I then get a response with both my existing settings, and the Joomla enforced setting as separate headings:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(self), camera=(), encrypted-media=(), fullscreen=(self), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(self), picture-in-picture=(), speaker=(), sync-xhr=(), usb=(), vr=()
Permissions-Policy: interest-cohort=()

Therefore it will be REALLY REALLY REALLY Important to ACCURATELY COMMUNICATE this b/c incompatible change if it is merged into Joomla 3.

Also Having the htaccess.txt having the Header always set Permissions-Policy "interest-cohort=()" enabled by default is probably not a good idea, because it will result in the above double value header. So I recommend its commented out in htaccess.txt with a HUGE commentary on why and what the issues are with enabling it. (I.e that if you enable it in .htaccess then you must disable it in joomla global config!)

I've updated the implementation. As @PhilETaylor noticed, my testing of the duplicate headers has been false. I handled the tool to display the headers wrongly, which resulted in this error. I apologise for this mistake. The goal is to send this header with every request from our server, so we would have to include it in our .htaccess. Since I couldn't find a reliable way to detect if this header has already been set when in the .htaccess, I commented the rule and added a pointer to our postinstall message.

The postinstall message has now also been correctly added to the install SQLs.

Regarding duplicate or overwritten headers: Again, I wasn't able to find a way to detect headers set in the .htaccess inside of PHP and my tests didn't allow me to read headers set by .htaccess. So if someone has set the Permissions-Policy in his .htaccess, our code would indeed add a duplicate header. If the header was set in PHP, I removed the $replace flag in order to not overwrite previously set headers. The code was initially inserted before the application is executed in order to catch as many requests as possible, but as with the .htaccess directive, the new position would be the safer solution while not being sent with every request.

I'm open for improvements to the postinstall message.

The OSM, Inc. - Full Board Meeting - April 22, 2021 minutes state:

The Production Department is looking into a way to support this feature but have it disabled by default for a release of Joomla! 3.9.27

But this PR makes it enabled by default.

Was there a decision to make this enabled by default or are the minutes incorrect? which is it?

I think that meant FLoC would be disabled by default

FYI now committed to Drupal core: https://www.drupal.org/project/drupal/issues/3209628

Thanks for letting us know @rachellawson much appreciated

@Hackwar There is still missing what @PhilETaylor wrote in his comment above as last:

(I.e that if you enable it in .htaccess then you must disable it in joomla global config!)

Even if in brackets, it is the most important information in order to avoid the duplicate and so invalid header value, and as far as I can see neither the comment in htaccess.txt nor the language strings tell that as clearly as Phil's comment.

But I think it should be done somewhere.

Update 2021-05-18Z14:21: Solved with d4cc16b .

I propose removing all references to Google.

"The FloC specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track" - apparently, whatever that means.

It is not "Google FloC" - although its authors are Google and Google are the first to use it, there is nothing stopping others from using the same tech

Edit; I see you removed one google in 3e8b5a8 but the concept needs applying to the language strings and elsewhere too.

We have a legal problem with this entire pull request and its accompanying text.

As has been pointed out above in the comments and the descriptions that accompany the code this is a political decision.

The Joomla! project disagrees that this feature is in the interests of the owners of Joomla!-powered websites as well as their visitors.

It doesn't improve Joomla in any way but purely exists to send a statement to Google that the Joomla project objects to this Federated Learning of Cohorts.

This creates a problem because OpenSourceMatters, the legal entity responsible for Joomla, passed a motion unanimously that was proposed by the Production Department Co-ordinator, a director of OpenSourceMatters, which specifically prohibits Joomla making a political statement on anything.

#2020/136 - Joomla is a non-political organisation and inclusive of everybody. In that context any public facing Joomla oriented communication should be void of political or otherwise offensive comments or references.
Proposed by Marco Dings, seconded by Luca Marzo.
The motion passed with unanimous consent.

This code and its accompanying text is clearly a political statement and as such is contrary to the above policy. The original intent may have been for the policy to address something completely different, we don't know as there is no record in the minutes of anything further. But legally it doesn't matter. The only thing that matters is the text of the motion that was proposed by Marco Dings and was approved.

The President of OpenSourceMatters was made aware, at the time that the motion was published in the minutes, that it would cause problems due to its wording and it was suggested that the policy should be either rejected as is or replaced with one that actually covered the issue it intended to address.. Additionally the President of OpenSourceMatters was made aware of this Pull Request when it was submitted and the legal issue was highlighted.

Unfortunately as neither of those have happened the rules have not changed and it is my belief (i am not a lawyer) that until OpenSourceMatters formally rescinds the above motion this Pull Request cannot be merged as it would be acting against its own rules.

My personal views about FLoC are irrelevant to the comments above.

As has been pointed out above in the comments and the descriptions that accompany the code this is a political decision.

The Joomla! project disagrees that this feature is in the interests of the owners of Joomla!-powered websites as well as their visitors.

Is it necessary to make a statement of belief at all? The text used in Drupal core is as follows:

/** 
 *
 * By default, Drupal sends the 'Permissions-Policy: interest-cohort=()' header
 * to disable Google's Federated Learning of Cohorts feature, introduced in
 * Chrome 89.
 *
 * See https://plausible.io/blog/google-floc for more information about FLoC.
 *
 * If you don't wish to disable FLoC in Chrome, you can set this value
 * to FALSE.
 */

No statement of belief, just what the setting does.

The text used in Drupal core is as follows:

Which links to an article https://plausible.io/blog/google-floc entitled "How to fight back against Google FLoC"... so hardly neutral on the point. :-)

@rachellawson The link in the comment is the de facto drupal statement. Drupal hopefully doesn't have such a badly worded policy that we are governed by

This PR is not political motivated we consider this technology as a risk for our user base not more not less. We just disable it as default but still let informed users the possibility to change the setting at anytime.

I have tested this item ✅ successfully on 1c30880

I have tested this item ✅ successfully on 1c30880

besides the wording...

RTC

@alikon Thanks for fixing the milestone. I see I've set the wrong one.

Thanks

i think this needs more fanfare....docs, tweet, marketing ...etc

I've discovered an issue. When I've tested this at home on my local Apache server, it worked like described in the comment in htaccess.txt that when I enabled the directive in the .htaccess file, I had to disable the "Block FLoC" in Global configuration in order not to get duplicate headers.

But now I've noticed that on my webspace, which is shared hosting by IONOS (formerly 1and1), it did not work like that. I had to use both, the backend block option and the htaccess directive, to get the header set for the page (i.e. the index.php file) and for real files like css, js, ...

The reason for this is following: On IONOS shared hosting, PHP runs as CGI, and in Apache configuration the "AllowOverride" parameter is set to false. That means that such htaccess directives like the new header or the nosniff header are not applied to PHP files.

So for this special case the comment in the htaccess.txt telling to switch off the blocker option in backend when enabling the htacess directive is wrong.

But to explain that in the comment in htaccess.txt might result in the comment being a bit long, especially if I have to write that explanation.

What shall we do? Make a PR to extend the comment by an explanation of that? Does someone have a proposal for a short enough text for the comment?

This fascination with .htaccess when joomla officially supports IIS and nginx too haha....

This fascination with .htaccess when joomla officially supports IIS and nginx too haha....

@PhilETaylor Is this your proposal for the helping comment in htaccess.txt? 😉

Yes, I know, "stay away from shared hosting".

HLeithner changed the title [3.9][SECURITY] Block usage of FLoC by default [3.9][Privacy] Block usage of FLoC by default yesterday

LMAO - So yesterday it was a SECURITY issue that needed to be flagged as such to break all the rules about new features in Joomla 3, but now its relabelled as a [Privacy] issue after its been added to Joomla 3... thus making this even more controversial.

Joomla 3.9.26 -> 27
PHP 7.4.16
Litespeed UK Servers

Just installed 3.9.27 with the FLoC Block set on as default and it gnarled an animation that starts on the open of my page. The animation was fine yesterday, but glitched on the update.

It also knocked about 3 to 4% from my GT Metrix performance on the same site.

Rebuilt the cache and recompiled the SCSS, but still misfired the anim, so turned of FLoC and bingo! It's back to normal.

So, no problem with the idea but is there another way of implementing this?

I see a suggestion of using .htaccess, is this a possibility?

With FLoC turned on I'm eyeballing a second or so delay on larger sites too.

I see a suggestion of using .htaccess, is this a possibility?

@dmleeman Yes. You can add (uncommented) section from the htaccess.txt to your .htaccess file:

## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
##
# Disable Federated Learning of Cohorts (FLoC)
# If you uncomment the below directive you have to allow this technology in the 
# Global Configuration of Joomla. Read more about this in the Post-Installation 
# message in the backend.
##
Header always set Permissions-Policy "interest-cohort=()"
</IfModule>

(The "nosniff" thing is not related to the FLoC but was added in past by another recommendation, see the postinstall messages in past.)

Then you should switch off the FLoC block in Global Configuration in order not to get that "Permissions-Policy" header duplicated.

There is one exception I've noticed on shared hosting of my provider (IONOS):

They run PHP as CGI and have the "AllowOverride" parameter set to false in the Apache config, so the header directive from .htaccess is not applied to PHP files, e.g. index.php. In such case you need both, the .htacess directive and the Global Configuration option.

it is concerning that this is having a performance and functionality impact!!

it is concerning that this is having a performance and functionality impact!!

"Allegedly" ... at this stage.

Permissions-Policy is not a new* header (its a renamed Feature Policy header) and so I find it incredible to believe that enabling such a thing would cause "3 to 4% from my GT Metrix performance"

@dmleeman please provide the before and after GTMetrix share urls with us.

*new = is a relative term.

Interesting Statistics

https://scotthelme.co.uk/what-the-floc/

There's only a total of 86 sites out of the top 1 million issuing a header that contains interest-cohort as of today, but that's still more than I was actually expecting! Also, another interesting point is that the vast majority of them seem to have added a Permissions Policy header purely for the purpose of opting out of FLoC interest-cohort=() 71. That's a lot of people now using Permissions Policy for one very specific purpose!

The list of 86 sites in that article too - and if adding such a header "made a site slow" or "broke things" then Im sure the sites in that list, including brave.com and duckduckgo.com would have complained about it by now ;-)

I think jumping to conclusions about this having a "performance and functionality impact" are probably unfounded.

Yup, not too proud of myself on this.

Just realised I had not set my gantry template from Dev to Production on the FLoC enabled test. Also had 3 other site admins open so may have checked the wrong ones.

Looks ok now I've compared them side by side properly.

Schoolboy error, must be due a day off

Thanks for letting us know. Pleased it was not the Joomla change :-)

Hello all,
Joomla lover and user since... 2010?
This is constructive criticism, so please understand it as such.

After reading the FLoC explainer, it seems that it increases privacy, by tracking only data relevant for ads through cohorts instead of individuals.
So it seems that it will be better than cookies in terms of privacy and more, cookies which are (obviously) accepted by everyone.

Would you care to explain why the the Joomla! project believes that this feature is not in the interests of owners of Joomla!-powered websites and their visitors?

Thank you

@molhokwai A simple google search for "floc bad" will bring up results from respected sites such as the Electronic Frontier Foundation (eff.com) and Wired.com explaining why FLoC is a bad idea.

Joomla gives you the option to enable or disable it... regardless of the politics surrounding it.

@PhilETaylor That is true, but the default value is a statement about whether the Joomla team believes that FLoC is a good thing or a bad thing. (And the consensus of privacy organisations worldwide is that it is a bad thing - and even Google has backtracked on it.)

This was debated considerably at the time, many agreed with you, however this is not the place to continue that discussion on the bottom of. a merged PR.

You have two choices, provide a PR to revert the inclusion of this feature for Joomla 5, or continue talking to the void.

@PhilETaylor I am in agreement that FLoC is a bad thing - so you will not be seeing a PR from me. I was just saying that whilst having an option is non-partisan, the choice of default value is a consensus (i.e. political in the definition you used) statement about the community view of FLoC.

the choice of default value is a consensus...statement about the community view of FLoC

I can assure you the "Joomla Community" had no say in the default chosen, and many people actually spoke out about this at the time. The decision was made in a private meeting, and implemented by someone with write access to the repo, and they were hell bent on pursuing it regardless of the opinions of the "Joomla Community".

@PhilETaylor Ahhh - the anarchy of open source where an individual with write access can do what they like and consensus is optional.

I have contributed to many open source projects, and they vary considerably in these areas. I have certainly contributed to projects with good ethics, and also one (a Joomla extension) where the project has effectively been destroyed by being taken over by a company who then decided that open source meant make it available for free but do limited maintenance and refuse all contribution from external users.

On the whole, my impression of the Joomla team/community is that there is a lot of collaboration and consensus building, but I guess there will always be exceptions.

Its documented above. There was a decision made and a person implemented it. There is no point discussing this further.

The decision was taken by OSM, Inc. - Full Board Meeting - April 22, 2021 https://volunteers.joomla.org/board-of-directors/reports/1495-osm-inc-full-board-meeting-april-22-2021

I can guarantee you, that I don't have write access to the Joomla repo (and for these exact reasons, I also don't want to have that access.) I brought the issue forward in a meeting of the production team and that escalated that to OSM. I've been vocal about this change and will defend it further, but I did not make the final decision. In the end, every decision has to be made by someone "in power", even if it is just through taking action. However, the teams involved made the decisions based on solid infos and based on feedback from the community.

However, the teams involved made the decisions based on solid infos and based on feedback from the community.

In private and against the wishes of "the community" actually but other than that... pushed into an existing series as a "security" issue when it has nothing to do with security, breaking Joomla's own rules on semver...

Google still has not even started its testing of FLOC/FLEDGE! So implementing this feature was way premature and could have waited for Joomla 4 after all...

https://www.privacysandbox.com/timeline/
https://searchengineland.com/google-pushes-back-floc-testing-to-q1-2022-374905

Google is considering a new algorithm and API for improvements from OT feedbacks. See https://datatracker.ietf.org/meeting/111/materials/slides-111-pearg-lets-talk-about-floc-00.
That could be incompatible with the current FLoC so that it is no longer needed to be public now. But it is their choice.

WICG/floc#133 (comment)

Today FLOC is not even a thing, the trials ended 14 Jul 2021 - the feature is redundant and a waste of bytes anyway

https://developer.chrome.com/origintrials/#/view_trial/213920982300098561

It was not my intent to provoke a flame war. As @PhilETaylor points out, FLoC is already dead in the water, so this feature is nugatory and should be reverted in due course.