Language Change PR-staging ?

Pending

User tests: Successful: Unsuccessful:

avatar Hackwar
Hackwar
20 Apr 2021

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.

avatar Hackwar Hackwar - open - 20 Apr 2021
avatar Hackwar Hackwar - change - 20 Apr 2021
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 20 Apr 2021
Category SQL Administration com_admin com_config Language & Strings Libraries
avatar PhilETaylor
PhilETaylor - comment - 20 Apr 2021

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

avatar Hackwar Hackwar - change - 20 Apr 2021
Labels Added: Language Change PR-staging
avatar PhilETaylor
PhilETaylor - comment - 20 Apr 2021

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.

avatar PhilETaylor
PhilETaylor - comment - 20 Apr 2021

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

avatar Hackwar
Hackwar - comment - 20 Apr 2021

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.

avatar Hackwar
Hackwar - comment - 20 Apr 2021

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.

avatar Hackwar
Hackwar - comment - 20 Apr 2021

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

avatar PhilETaylor
PhilETaylor - comment - 20 Apr 2021

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.

avatar PhilETaylor
PhilETaylor - comment - 20 Apr 2021

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

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

avatar PhilETaylor
PhilETaylor - comment - 20 Apr 2021

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.

avatar brianteeman
brianteeman - comment - 20 Apr 2021

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

avatar Hackwar
Hackwar - comment - 21 Apr 2021

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.

avatar richard67
richard67 - comment - 21 Apr 2021

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

avatar joomla-cms-bot joomla-cms-bot - change - 21 Apr 2021
Category SQL Administration com_admin com_config Language & Strings Libraries SQL Administration com_admin Postgresql MS SQL com_config Language & Strings Libraries
avatar Hackwar
Hackwar - comment - 21 Apr 2021

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

avatar bembelimen
bembelimen - comment - 21 Apr 2021

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

avatar dgrammatiko
dgrammatiko - comment - 21 Apr 2021

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

avatar PhilETaylor
PhilETaylor - comment - 21 Apr 2021

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?

avatar Hackwar
Hackwar - comment - 21 Apr 2021

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.

avatar rodlie
rodlie - comment - 22 Apr 2021

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

avatar nikosdion
nikosdion - comment - 23 Apr 2021

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.

avatar brianteeman
brianteeman - comment - 23 Apr 2021

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.

avatar ReLater
ReLater - comment - 23 Apr 2021

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.

avatar brianteeman
brianteeman - comment - 23 Apr 2021

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

avatar PhilETaylor
PhilETaylor - comment - 28 Apr 2021

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

avatar brianteeman
brianteeman - comment - 29 Apr 2021

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

image

avatar PhilETaylor
PhilETaylor - comment - 29 Apr 2021

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

avatar PhilETaylor
PhilETaylor - comment - 29 Apr 2021

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

avatar joomla-cms-bot joomla-cms-bot - change - 29 Apr 2021
Category SQL Administration com_admin com_config Language & Strings Libraries Postgresql MS SQL SQL Administration com_admin Postgresql MS SQL com_config Language & Strings Installation Libraries
avatar Hackwar
Hackwar - comment - 29 Apr 2021

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.

avatar PhilETaylor
PhilETaylor - comment - 3 May 2021

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?

avatar brianteeman
brianteeman - comment - 3 May 2021

I think that meant FLoC would be disabled by default

avatar rachellawson
rachellawson - comment - 15 May 2021

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

avatar brianteeman
brianteeman - comment - 15 May 2021

Thanks for letting us know @rachellawson much appreciated

avatar richard67
richard67 - comment - 17 May 2021

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

avatar PhilETaylor
PhilETaylor - comment - 18 May 2021

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.

avatar brianteeman
brianteeman - comment - 18 May 2021

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.

avatar rachellawson
rachellawson - comment - 18 May 2021

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.

avatar PhilETaylor
PhilETaylor - comment - 18 May 2021

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

avatar brianteeman
brianteeman - comment - 18 May 2021

@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

avatar HLeithner
HLeithner - comment - 18 May 2021

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.

avatar richard67 richard67 - test_item - 18 May 2021 - Tested successfully
avatar richard67
richard67 - comment - 18 May 2021

I have tested this item successfully on 1c30880


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

avatar alikon alikon - test_item - 18 May 2021 - Tested successfully
avatar alikon
alikon - comment - 18 May 2021

I have tested this item successfully on 1c30880

besides the wording...


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

avatar alikon alikon - change - 18 May 2021
Status Pending Ready to Commit
avatar alikon
alikon - comment - 18 May 2021

RTC


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

avatar richard67
richard67 - comment - 18 May 2021

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

avatar HLeithner HLeithner - change - 18 May 2021
Status Ready to Commit Fixed in Code Base
Closed_Date 0000-00-00 00:00:00 2021-05-18 18:45:39
Closed_By HLeithner
Labels Added: ?
avatar HLeithner HLeithner - close - 18 May 2021
avatar HLeithner HLeithner - merge - 18 May 2021
avatar HLeithner
HLeithner - comment - 18 May 2021

Thanks

avatar alikon
alikon - comment - 18 May 2021

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

avatar richard67
richard67 - comment - 19 May 2021

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?

avatar PhilETaylor
PhilETaylor - comment - 19 May 2021

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

avatar richard67
richard67 - comment - 19 May 2021

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

avatar richard67
richard67 - comment - 19 May 2021

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

avatar HLeithner HLeithner - change - 24 May 2021
Title
[3.9][SECURITY] Block usage of FLoC by default
[3.9][Privacy] Block usage of FLoC by default
avatar HLeithner HLeithner - edited - 24 May 2021
avatar PhilETaylor
PhilETaylor - comment - 25 May 2021

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.

avatar dmleeman
dmleeman - comment - 26 May 2021

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.

avatar dmleeman
dmleeman - comment - 26 May 2021

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.

avatar richard67
richard67 - comment - 26 May 2021

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.

avatar brianteeman
brianteeman - comment - 26 May 2021

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

avatar PhilETaylor
PhilETaylor - comment - 26 May 2021

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.

avatar dmleeman
dmleeman - comment - 26 May 2021

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

avatar PhilETaylor
PhilETaylor - comment - 26 May 2021

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

Add a Comment

Login with GitHub to post a comment