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
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 set cookies other than what is absolutely necessary for logging in a user and maintaining their login security.
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.