If you check you will see that this code is already present

If you check you will see that this code is already present

joomla-cms/htaccess.txt

Lines 27 to 34 in f66176f

	##
	# 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>

but it is commented out...
so as I can understand - it doesn't work from the box?

If you read the post installation message related to FLoC you will understand

If you check you will see that this code is already present

joomla-cms/htaccess.txt

Lines 27 to 34 in f66176f

	##
	# 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>

Yep, I've seen it. But my idea is described on the screenshot:

There are 2 URLs on detailed guides, but why not to give short recommendations on updating .htaccess as in the previous
message? What do you think?

And what is not clear for me yet:
Is it enough just to keep the new FLoC option enabled (what is the default after updating the site to J 3.9.27) or we need to update .htaccess with extra line for full FLoC opt-out?
So, is it an extra action or a duplication of each other?

If you read the post installation message related to FLoC you will understand

the message is unclear not only for me but for many others people. So this question was asked to clear this

As stated in the message it is enabled by default for everything accessed through joomla

However if you additionally want to block it for all requests to the server then you can use the suggested htaccess code.

Lets also remember .htaccess is only ONE vendor specific ruleset (for Apache) (although litespeed will parse it, Joomla officially doesnt support installation on litespeed servers)

Therefore enabling it by default in .htaccess will not activate this server on 100% of sites. (for example on ISS or Nginx based servers)

So, is it an extra action or a duplication of each other?

You need EITHER the .htaccess OR the Global Configuration setting - not both.

If you implement at the .htaccess level then ALL requests will respond with a header.

If you implement at the Global Configuration level then ALL requests THAT GO THROUGH index.php will respond with a header.

If you implement at the .htaccess level and at the Global Configuration level then:

• requests that go through index.php will have duplicated headers - which is bad!
• requests that dont go through index.php will have the feature activated as a header.

Furthermore, you need to architect your website in such a way that adding this new header is in ADDITION to any EXISTING Permissions Policy (or Feature Policy) you already output. Simply blindly enabling a feature like this can overwrite, or even duplicate headers. It needs thought and design.

Lets also remember .htaccess is only ONE vendor specific ruleset (for Apache) (although litespeed will parse it, Joomla officially doesnt support installation on litespeed servers)

Therefore enabling it by default in .htaccess will not activate this server on 100% of sites. (for example on ISS or Nginx based servers)

So, is it an extra action or a duplication of each other?

You need EITHER the .htaccess OR the Global Configuration setting - not both.

If you implement at the .htaccess level then ALL requests will respond with a header.

If you implement at the Global Configuration level then ALL requests THAT GO THROUGH index.php will respond with a header.

If you implement at the .htaccess level and at the Global Configuration level then:

* requests that go through index.php will have duplicated headers - which is bad!

* requests that dont go through index.php will have the feature activated as a header.

Furthermore, you need to architect your website in such a way that adding this new header is in ADDITION to any EXISTING Permissions Policy (or Feature Policy) you already output. Simply blindly enabling a feature like this can overwrite, or even duplicate headers. It needs thought and design.

Thank you for the full and clear explanation!

Thank you, Phil.