#35288 – Does the htaccess file need to be modified for FLoC since Joomla 3.9.27?

Posted in ‘Akeeba Admin Tools for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Tuesday, 25 May 2021 14:33 CDT
WoodyF4u

After the update to Joomla 3.9.27 this message appears:

Block Federated Learning of Cohorts (FLoC)

Since version 3.9.27

A new technology is currently being rolled out to browsers to replace third party tracking cookies. This technology is named Federated Learning of Cohorts (FLoC) and you can read more about it here and here. Starting with Joomla! 3.9.27 your website blocks this technology, you can re-allow it from the Global Configuration. Additionally to disable this technology for all requests to your server, you have to update your .htaccess.
 I always have the htaccess file created by AdminTools.
Is the described adjustment necessary or is it better not to adjust it?    

Custom Fields

Joomla! version (in x.y.z format) 3.9.27
PHP version (in x.y.z format) 7.4.16
Admin Tools version (x.y.z format) 6.0.6
Best regards,
Wouter (WoodyF4u)
Wednesday, 26 May 2021 01:46 CDT
nicholas

No.

The whole FLoC thing is lots of fear-mongering, decisions made without fully understanding the problem at hand and shoddy implementation by the same developer who for two whole years failed to develop a trivial Mail Templates component for Joomla 4.

I have already told the Joomla core contributors why their decision and approach is wrong on their official GitHub repository, publicly, so they can no longer pretend that I never warn them about their mistakes before they get to make them.

In any case, "blocking FLoC" is absolutely and most categorically NOT a security improvement for your site. It has nothing to do whatsoever with security. It's not even a privacy improvement for your site's users in most cases. Moreover, the so-called "blocking" can be overridden.

Now, on to the technical implementation side. Blocking FLoC requires adding something to your Permissions-Policy header. This header determines all sorts of permissions for which browser features are enabled and how they behave. This needs to be carefully constructed, ideally per section or page of your site. Apache does not have a way to add or remove content from a header; it only has a way to override a header. This is what Joomla did in their .htaccess. However, overriding this header in the .htaccess is a horrible idea for security as Phil Taylor explained a couple of comments below mine in the link I provided.

In other words, Joomla's so-called "security" and "privacy" feature is neither and the implementation will either have currently no effect at best or, if you're already using a Permissions-Policy header like we do, in fact DETERIORATE THE SECURITY OF YOUR SITE BY UNDOING THE Permissions-Policy HEADER YOU ARE SENDING. In other words, not only does it fail to block a browser feature which has NOT shipped yet and which will be very likely be opt-in when it ships but it also undoes protections you may have put in place to prevent privacy and security issues for your visitors from technologies which are shipping with browsers right now and are used to track or trick users!

I did read the same Hacker News and The Register articles as everyone else. I did write an implementation for Admin Tools. Then I stopped writing code and started thinking. Does this make sense? What are the implications? I spent the entire day of April 20th educating myself and I quickly realised that "blocking FLoC" is premature, doesn't actually work (Google conveniently added a backdoor to IFRAMEs so it can still serve ads through its own ad network; who'd 'a' thunk...) and the implementation would actually degrade real security measures. That's why I put this feature on ice and recommend that users DO NOT try to follow Joomla's disastrous recommendation in their .htaccess.

If you have a Permissions-Policy in your .htaccess and are so inclined you can add ;interest-cohort=() there as long as you understand that a. it only makes sense if you are serving ads on your site which use JavaScript but DON'T create an IFRAME; and b. it's a PR stunt which removes the choices from your site's visitors and might actually undermine their privacy, especially if they live under or oppose a repressive regime.

It is my professional opinion that we need to first wait until Google launches (or kills) the FLoC feature before we decide whether blocking it is necessary and doesn't hurt the privacy of individuals.

In the end of they day, if you are so concerned about your user's privacy you can do a few simple things we are already doing here at akeeba.com:

  • DO NOT serve ads. Monetize your content a different way e.g. Patreon.
  • DO NOT use third party analytics services. We analyse the Apache logs using AWStats.
  • DO NOT embed videos, Instagram posts, Tweets or any other content from third party sites. We refrain from doing that and our videos are hosted on our own CDN, played with self-hosted JavaScript. 
  • DO NOT use social login or share buttons which load JavaScript from third party origins. We don't do that and if we ever added social logins it would be with our own SocialLogin extension which does NOT use third party JavaScript or third party cookies.
  • DO NOT set cookies other than what is absolutely necessary for logging in a user and maintaining their login security.

The only exception we HAVE to make is when you are purchasing a subscription. We have no choice there but to load third party JavaScript. Even so, you can block most of the tracking they do — except what they do for fraud prevention, this is required by financial regulators — using Privacy Badger on your browser.

Anything else would be a meaningless PR stunt. We are not in the business of meaningless PR stunts (also known as "selling snake oil"). We are in the business of providing real security for your sites. "Blocking FLoC" is snake oil. Don't buy into it.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 26 May 2021 03:35 CDT
WoodyF4u

Hi Nicholas,

thank you very much for this very detailed explanation.
Last night I also read several posts on the internet about FLoC and I actually came to almost the same conclusion.
Your explanation supports my thoughts.

I still want to ask you the following, even if this does not concern your extensions.
In Joola 3.9,27 FLoC is blocked (Yes) in the Global Configuration.
If I understand your explanation correctly, it is better to set this to No again.
Is that right?

Best regards,
Wouter (WoodyF4u)
Wednesday, 26 May 2021 05:30 CDT
nicholas

Correct. I've said that to No on our site.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 26 May 2021 05:37 CDT
WoodyF4u

Thanks.

That's clear.

Best regards,
Wouter (WoodyF4u)
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!