Posted April 21, 2021 Paweł Czerwiński on Unsplash

What Google's FLoC Means for Web Developers.


If you’ve been paying any attention recently to the world of web security, you’ve no doubt heard rumblings and mentions of Google’s latest attempt to replace third-party tracking cookies: Federated Learning of Cohorts, or FLoC.

FLoC aims to replace third-party tracking by moving data collection to the user’s browser. According to the whitepaper published by the Google Research & Ads team a few months back, FLoC presents itself as a “privacy preserving mechanism” that aims to “preserve interest based advertising.” It plans to do this via a Javascript API that assigns users to “cohorts,” or groups with similar interests and similarly visited sites.

In order to keep data tracking persistent across cohorts and allow for the differentiation of specific users, FLoC’s API generates unique IDs for all cohorts by using a hashing technique called “SimHash”. With all of these methods combined, alongside others mentioned in the whitepaper, Google guarantees that with their new tracking methodology, interest-based advertising can remain while still keeping users “private”. Although, this claim is considered dubious at best by multiple, respected privacy advocates and media outlets, including the EFF.

One of the concerns I see mentioned repeatedly is that FLoC doesn’t address or seem to bypass “discrimination and predatory targeting,” according to the EFF. Another concern about FLoC is that it doesn’t contain any features, right now at least, that allows the user to decide what data they retain and share, if at all. It seems like FLoC doesn’t change or remove the practice of invasive targeting, it just moves the methodology.

What all of this means to web developers is, as I am typing this, not fully known. There are a few “solutions” to blocking FLoC cohorts data collection from your site via a simple HTTP header, but this isn’t a band-aid fix as one would think. While the addition of the Permissions-Policy header is a step in the right direction, it isn’t a fix-all.

So, what can web developers do to combat FLoC in our own systems? Right now, there’s really only two things to do: include the aforementioned Permissions-Policy HTTP header for every page on your site and never use the document.interestCohort() function from the FLoC Javascript API anywhere on your site. However, via a post from Google’s web development blog, any sites that “[load] ads or ads-related resource[s],” or anything that triggers Chromium’s ad tagger, will also trigger the FLoC trial for supported Chrome versions. Meaning that if your site uses third-party ad services, it will more than likely be opted-in to the FLoC trial even if you or your third-party ad systems don’t explicitly use the interestCohort function.

The most reliable way to keep FLoC away from your site is to do the following, according to Rohan Kumar:

As mentioned before, FLoC is still in an origin trial phase as of the creation of this post. There are a lot of unknowns and uncertainties right now, so a lot of misinformation, done with malice or not, is going around. However, the origin of blame should not be on the web developers and system administrators of sites that don’t enact these precautions against FLoC, but instead the onus should be on Google and their R&D teams for creating FLoC in the first place.

FLoC may not exactly be the scary beast that some may portray it to be, but it sure as hell isn’t a solution to any preexisting concerns over invasive tracking.

Want to leave a comment?

I don't allow public comments on my blog because moderation is a pain and I have things to do, ya' know? If you want to leave a comment about my post, head on over to my contact page and get in touch with me there!