There has been a lot of talk lately surrounding Google’s Federated Learning of Cohorts (FLoC) initiative, which is quickly becoming a hot-button topic both in the tech community and major mainstream publications.
In this blog post, we’ll cover what Google FLoC is, why it matters, and how we’ve made it easy to disable it in RunCloud.
What Is Google FLoC & Why It Matters
FLoC is a proposed feature by Google that lets browsers collect, profile, and store usage patterns based on a user’s browsing habits over time.
This new type of tracking, which is done directly within the browser, would then be used by Google and its advertising partners for widespread tracking and personalization of ads.
FLoC is part of a larger response by Google to the slow decay (and increased blocking) of third-party cookies on the web. Why? Because as users become more privacy-aware, the ease of tracking and identifying them across multiple websites for the purposes of advertising and surveillance has become much more difficult in recent years.
With the proposed FLoC feature enabled, the browser will create “cohorts” that group users with similar browsing habits together. This cohort ID will grow in size and relevance as it continually gathers information about the sites that users visit, the ads that they view, their behavioral patterns, how often they browse, etc.
Each individual cohort is then combined with other cohort IDs when sent to Google, who will then display ads to individual users based on the relevancy of the data that has been collected within their shared cohort.
Why FLoC Is Considered Premature
In the acronym for FLoC, the word cohort was carefully chosen. A cohort is defined as a “group of individuals having a statistics factor in common”.
Google’s promise is that FLoC cohort IDs will be anonymous data points in a larger network and that each cohort’s data will be sent to advertisers without them knowing the identity of individual users.
The problem with FLoC however is two-fold, both in principle and in practice.
Principally, the user’s browser is supposed to be sacred. It’s simply a tool to interact with the larger web. FLoC aims to turn the browser into a real-time tracking mechanism that collects the most sensitive information about an individual user’s browsing habits without the user being able to circumvent or opt out of this data collection.
In practical terms, it’s not difficult for advertisers to understand and identify patterns once the FLoC data set becomes large enough. For example, cohorts comprised of users that share the same location data, shop in the same neighborhood, are active in the same time zone, etc. can be easily grouped together by demographic.
To make matters worse,, if FLoC data is used in combination with other tracking mechanisms such as social media analytics, existing third-party cookies, or data sets purchased from data brokers, it becomes a trivial task to fingerprint users based on age, class, ethnicity, political parties, etc.
Why FLoC Sets A Dangerous Precedent
Google announced that in Chrome version 89 they will forcibly enable and trial their FLoC data-collection initiative without the consent of users or webmasters.
The Electronic Frontier Foundation was one of the first privacy advocates to bring to light the dangers of this announcement. They correctly pointed out that instead of reducing the overreach of personalized tracking in the ad-tech industry, Google is now seeking to leverage it’s Chrome browser to do the data mining itself.
Google Chrome’s market share is currently pegged at almost 70%. That represents more than two-thirds of the entire user base of the web. Once the FLoC rollout has exited it’s current beta stage and is mainlined into the Chrome codebase, it immediately begins profiling the majority of Internet users and sends that information straight to Google.
Other browser vendors such as Mozilla Firefox, Brave, Microsoft Edge, Vivaldi, and Opera have recently weighed in on FLoC, some of them making broader statements as they wait to see how the situation unfolds, while others have already chosen not to support any such data aggregation efforts whatsoever.
The most notable response is that of Brave, with an entire blog post that opens with this clear statement:
Brave opposes FLoC, along with any other feature designed to share information about you and your interests without your fully informed consent. The privacy-affecting aspects of FLoC have never been enabled in Brave releases […] Brave is also disabling FLoC on our websites, to protect Chrome users learning about Brave.
How to Opt Out of FLoC Data Collection
For end-users, the easiest choice when it comes to opting out of FLoC’s data collection is simply not to use Chrome. However, a Chrome Extension was released by DuckDuckGo that disables FLoC tracking within the browser. If this extension will be disabled by Google or simply ignored by the browser itself is yet to be seen.
The larger point of contention however lies with webmasters and web server administrators. FLoC requires that a website provide an explicit HTTP response header if it wants to opt out of the program. This suggests that Google is counting on webmasters to not be bothered with this task.
The Easiest Way To Opt Out of FLoC (with RunCloud)
Manually inserting the necessary FLoC header in your web server configuration, and then reproducing this for multiple applications is quite time-consuming. Fortunately, RunCloud makes this easier than ever – we’ve integrated the necessary pre-defined HTTP headers for all users so they can disable FLoC in less than a minute.
Once logged in, navigate to your server, and under Web Applications > NGINX Config you’ll be able to select and add the required config rule. After adding the required headers, the next step is to clear your NGINX FastCGI cache (RunCache) and then test your website or web application to ensure the headers are being delivered.
We’re currently implementing a similar feature to support websites and applications using the OpenLiteSpeed web server and will be rolling it out in the coming days.
If you choose not to opt out of FLoC as a website owner, you are helping Google to add more profiling data on your visitors by leveraging your website as a data point that adds to the user’s fingerprint on the web. Opting out of Google’s new FLoC initiative & protect your users in a matter of less than a minute with the help of RunCloud – here’s how:
So if you’re a RunCloud user and currently using a server that runs on NGINX, opting out couldn’t be easier – in just a few clicks.
Alternatively, in order to opt your website out of the FLoC network, webmasters need to add a custom HTTP response header to their website to be served with each request. This comes in the form of a Permissions-Policy header, with the following syntax:
Permissions-Policy: interest-cohort=()
For the popular NGINX web server, this can be achieved with the add_header directive, which needs to be added to each website’s configuration file. The following code snippet shows the syntax that’s required:
server {
location / {
add_header Permissions-Policy interest-cohort=();
...
}
}After adding the snippet to your configuration file, you’ll need to reload NGINX in order for the changes to take effect.
NGINX has built-in syntax checking that should be used in combination with a reload or restart, the following command will do both:
nginx -t && service nginx reloadOnce enabled in NGINX, the Permissions-Policy header will be respected by Chrome and disables FLoC data collection for users that visit your website — in other words, your website will not be used as a profiling data point for your users’ browsing habits.
Opting Out of Google FLoC on OpenLiteSpeed (RunCLoud)
If you’re using the similarly popular OpenLiteSpeed web server, you can add the necessary FLoC header by editing your vHost configuration file (vhost.conf) which is located in the /usr/local/lsws/conf/MY_VHOST/ directory.
OpenLiteSpeed uses what are called Contexts for adding custom headers and other functionality to a web application. In the example below, we’ll be adding the following code to the root context in an example WordPress configuration located at /usr/local/lsws/conf/vhosts/wordpress/vhconf.conf:
context / {
location $DOC_ROOT
allowBrowse 1
note This header disables FLoC
extraHeaders set Permissions-Policy interest-cohort=()
}If you use RunCloud to manage your OpenLiteSpeed servers, adding the above snippet to your configuration file is as easy as navigating to your server and under LiteSpeed Server Config:
The Context snippet can be placed after your Index directive. And, fortunately – with RunCloud, there’s no need to manually restart OpenLiteSpeed. After you’ve inserted the snippet and click Update Config, we automatically enable the configuration changes under the hood.
Otherwise, after saving the changes to your configuration file – you’ll need to do a graceful restart of OpenLiteSpeed in order for the changes to take effect. The following command will achieve that:
systemctl restart lswsOpting Out of Google FLoC on OpenLiteSpeed (Non-RunCloud Method)
If you prefer to use the graphical OpenLiteSpeed WebAdmin Console instead, you can achieve the same functionality with the following steps outlined in the screenshots below.
The OpenLiteSpeed WebAdmin runs on port 7080, which would be closed by default in your firewall.
To enable access to that port via UFW, use the following command:
ufw allow 7080UFW stands for Uncomplicated Firewall and is an extremely popular and easy-to-use wrapper around IPTables firewall rules. Most Linux distributions come with it pre-installed, but you can manually install it for your distribution.
For Debian/Ubuntu run the following command:
sudo apt install ufw -yFor servers using CentOS, run the following command:
yum install ufw -yUFW will not be immediately active by default. But before activating it, it’s important to set the necessary default rules:
ufw default deny incoming
ufw default allow outgoingAnd then use UFW’s syntax to add common ports that you’ll need on your server:
ufw allow ssh
ufw allow http
ufw allow httpsThose rules take care of SSH (else you’ll be locked out when you try to reconnect), as well as HTTP and HTTPS web traffic.
You can now enable UFW by running:
ufw enableYou can check the status of your firewall by running ufw status
Finally, add the custom rule for OpenLiteSpeed WebAdminwhich will be active immediately:
ufw allow 7080Next, login to your WebAdmin Console which is located at http://YOUR_SERVER_IP:7080 and navigate to the list of Virtual Hosts:
Next, select the Virtual Host that you wish to edit. In this case we’ll be editing “wordpress”. Select the + icon to add a new Context:
Choose Static as the context type and press the Next icon:
There are a number of fields available when adding Contexts from within the WebAdmin console. For the purposes of disabling FLoC, only the following fields need to be populated:
The URI scheme and whether it’s Accessible or not are mandatory fields.
The $DOC_ROOT is not strictly needed, but it’s better to utilize this variable as OpenLiteSpeed uses it internally to match your website’s document root.
The Notes field is optional as well but is useful for displaying what the rule does in the WebAdmin list of Contexts.
Finally, the Header Operations is where we set the FLoC header.
As with the CLI, you’ll need to do a graceful restart of OpenLiteSpeed for these changes to take effect. You can do so by clicking on the green Restart button located next to the process ID (PID) of OpenLiteSpeed:
When you’re finished in the WebAdmin Console, remember to restrict access to this port by denying connections in your firewall using UFW:
ufw deny 7080How To Disable/Opt Out of Google FLoC (WordPress Plugin Method)
If you use WordPress & wish to go the less technical route º there’s an open-source plugin that will add the necessary Permissions-Policy headers to your website.
In your dashboard, head to Plugins > Add New and search for Disable FLoC by Roy Tanck. This plugin author has developed numerous plugins and is also a core contributor to WordPress.
More importantly, this plugin will not overwrite or otherwise interfere with any existing Permissions-Policy or other security headers you’ve configured…
Verifying FLoC protections in RunCloud
After enabling your custom RunCloud headers to disable FLoC, you can verify the existence of the headers in a number of ways.
The easiest method is to test your website online using securityheaders.com, which should display the Permissions-Policy interest-cohort=() string in the list of headers.
If you’re comfortable on the command line, you can use the curl utility to inspect your website’s headers, with the following command:
curl -I https://mywebsite.com
The output should contain the string permissions-policy: interest-cohort=()
Lastly, you can use your browser’s DevTools to inspect headers. Visit your website and open your browser’s DevTools with the shortcut CTRL + Shift + C. Navigate to the Network tab and you’ll be prompted to Reload your page to inspect the requests and responses.
Once you’ve reloaded your page the first item in the list is the HTML of the page itself (with a GET/200 request/response code). Click on that entry, and on the right-side panel under the Headers tab you’ll be able to view all the response headers; of which permissions-policy: interest-cohort=() should be there.
Summary – Say No To FLoC, Protect Your Users
Following the announcement of Google FLoC, our team was excited to be able to provide our users an effortless opt-out process because we believe privacy should always be an option, control should belong to the website owner – if not the users themselves…
Want to share your thoughts on Google’s FLoC intiative or have any other questions about opting out? Let us know & join the conversation by leaving a comment below. 💬
