[3.9][Privacy] Block usage of FLoC by default

[Hackwar]

Issue

As a replacement for third party cookies, Google has introduced the Federated Learning of Cohorts into the Chrome browser lately. This feature is supposed to allow better tracking of users while also keeping data privacy. Details can be read here. The Joomla! project disagrees that this feature is in the interests of the owners of Joomla!-powered websites as well as their visitors. We share the assessment of the EFF as well as many other organisations (Mozilla, Microsoft, Opera, WordPress).

We consider this a security issue and thus will roll out countermeasures with the next bugfix release of the Joomla 3.9 series.

Summary of Changes

This PR introduces a header to disable Federated Learning of Cohorts, which is sent with every request that is handled by the Joomla framework. The header specifically looks like this:
Permissions-Policy: interest-cohort=()
and is the equivalent of opting out of this feature. Please be aware that this only adds this header to requests which go through the Joomla! application. 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.

If you really want to disable the blocking of this feature, we added a switch in the global configuration to remove this header.

A postinstall message has been added to the database to inform administrators of this decision.

Testing Instructions

Apply this patch and load a random page of your testing site. The answer to your request should contain the above noted header.

Documentation Changes Required

None.

Handling of this in the future

This PR fixes this issue for the 3.9 and 3.10 releases. We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

[Hackwar]

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.

[Hackwar]

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.

[Hackwar]

"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.

[brianteeman]

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

[Hackwar]

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.

[richard67]

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

[Hackwar]

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

[bembelimen]

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

[dgrammatiko]

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)?

[Hackwar]

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.

[rodlie]

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).

[richard67]

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?

[richard67]

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? 😉

[richard67]

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

[dmleeman]

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?

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33212.}

[dmleeman]

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

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33212.}

[richard67]

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.

[brianteeman]

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

[dmleeman]

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

[molhokwai]

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

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33212.}

[Sophist-UK]

@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.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33212.}

[Sophist-UK]

@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.)

[Sophist-UK]

@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.

[Sophist-UK]

@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.

[Hackwar]

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.

[Sophist-UK]

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.