Beyond Web Cookies: Google’s FLoC

A lone Canadian Goose sits among a flock of ducks sitting in the snow.
You’re about as “anonymous” as the goose in this flock with FLoC.
Image source – https://www.flickr.com/photos/see-through-the-eye-of-g/5480240484/ (CC BY 2.0)

It’s been a while since we last wrote about the many ways companies track users with cookies and beyond. This week we’re coming back to our “Beyond Web Cookies” series with the latest development in site tracking and why your library should consider opting out to protect patron privacy.

(Puns in this post are fully intended.)

Ditching the Cookie for the FLoC

 Web cookies come in several flavors, from session and persistent cookies to first- and third-party cookies. A cookie can track your behavior online, across sites, and collect personal information for marketing, advertising, and other purposes. End users can block cookies through various browser settings and plugins, but that blocking can only go so far when websites find alternative ways to track users beyond web cookies, such as privacy-invasive WordPress plugins. Nonetheless, the majority of companies rely on cookies to collect information for marketing and advertising to end-users. When end users block cookies, the company that relies on advertising revenue has limited options in creating targeted marketing.

Enter Google. Early in 2021, Google announced a new ad-tech called the Federated Learning of Cohort, or FLoC, that reports being less privacy-invasive than web cookies. This “privacy-first” technology aims to create large groups of people with similar interests based on browsing activity. Advertisers can then target these large groups grouped by topics without the possibility of identifying unique individuals through tracking data. Sounds too good to be true, right?

FLoC’ing Problems

While FloC promises a privacy-preserving way to continue making money through advertising, the ad-tech does not escape the potential of violating user privacy. The first problem is, well, Google. Google already has many ways to track users outside of Google Analytics through their products and sites that use Google APIs and services. As Shoshana Wodinsky points out, FLoC expands Google’s access to user data in the online advertising world, giving Google almost full unrestricted access to user data used for targeted advertising. Wodinsky points out that FLoC’s grouping of people by topics can lead the system to create groups of people around sensitive, personal topics. That grouping creates potential future harm and discrimination if these groups were part of a data leak or breach. Grouping people by topic will most likely increase predatory targeting, scams, and discrimination practices.

FLoC’s promise of privacy is weakened further by continuing the cross-site tracking behavior we find in web cookies, but with a twist. According to FLoC, the information gathered about a user’s browsing history can be matched up to other trackers that already have personally identifiable information. If a user logs into a site and doesn’t log back out for the duration of their browsing session, this service can potentially take the FLoC information and tie it back to the user account.

Getting the FLoC Out to Protect Patron Privacy

Google recently rolled out a “test” of FLoC to a random group of Chrome users. If you are not sure if you are in this test group, visit EFF’s Am I FloCed? to check if your Chrome browser has FLoC enabled. Google claims that there will be an opt-out option for Chrome users by April, but it’s late April and there is no sign of the opt-out option. Libraries can help patrons protect their privacy by disabling third-party cookies in the Chrome browser settings on public computers in addition to installing privacy-preserving browser plugins and privacy-preserving browsers such as Brave and Tor.

How can libraries protect patrons from having their activity tracked on library websites and services? Libraries that have some control over their library website can include an opt-out in the HTTP header of the library website. However, this might not be an option for libraries that do not have that level of control over their website or the server that hosts their library website. There are some workarounds to this, such as the FLoC opt-out plugins for WordPress (disclosure – LDH has installed the Disable FLoC plugin to opt-out of the FLoC test).

But what about vendor sites? You can use https://tanck.nl/floc-check/ to find out if a website has opted out of FLoC. Vendor sites that have not opted out of FLoC might not be aware that their website is included in this test. Use this opportunity to talk to your vendor about FLoC and ask how they will protect the privacy of your patrons on their site. This is also an opportunity to check your vendor’s privacy policy and contracts to find if your vendor is collecting patron data for advertising and marketing purposes. Now is the time to renegotiate those terms or start shopping for other vendors that better protect patron privacy if the vendor won’t budge on their use of patron data for advertising.

In short, FLoC doesn’t really replace cookies. Instead, it adds more personal information – some of it sensitive – into the targeted advertising environment controlled by one company. Because FLoC includes all websites into the FLoC test by default, libraries must take action to protect patron privacy now to ensure that patron data does not end up in the ever-growing collection of and access to user data by Google.

Beyond Web Cookies: The Ways Google Tracks Your Users

Welcome to this week’s Tip of the Hat!

Earlier we discussed the basics of web cookies, including the cookies used in tracking applications such as Google Analytics. However, there are many ways Google can track your online behavior even when you block Google Analytics cookies and avoid using Google Chrome. Because Google provides applications and infrastructure for many web developers to use on their sites, it’s extremely hard to avoid Google when you are browsing the Web.

An example of this is Google Fonts. The LDH website uses a font provided by the service. To use the font, the following code is inserted into the web page HTML code:

link href=”https://fonts.googleapis.com/css?family=Open+Sans&display=swap” rel=”stylesheet”

For those who are not familiar with HTML code, the above line is instructing the web page to pull in the font style from the external fonts.googleapis.com site. The FAQ question about user privacy describes the data exchanged between our site and the Google Font API service. The exact data mentioned in the FAQ is limited to the number of requests for the specific font family and the font file itself. On the surface, the answer seems reasonable, though there is always the possibility of omission of detail in the answer.

This isn’t to say that other Google services provide the same type of assurance, though. In Vanderbilt University Professor Douglas C. Schmidt’s research study about how Google tracks users, many other Google services that collect data that can be tied back to individuals. Schmidt’s study leans heavily toward tracking through mobile devices, but the study does cover how users can be tracked even through the exclusive use of non-Google products thanks to the pervasiveness of third-party tracking and services that feed data back to Google.

We covered some ways that you can avoid being tracked by Google as a web user in our earlier newsletter, including browser add-ons that block cookies and other trackers. Some of the same add-ons and browsers block other ways that Google tracks web users. Still, there is the same question that we brought up in the earlier newsletters – what can web developers and web site owners do to protect the privacy of their users?

First, take an audit of the Google products and API services you’re currently using in your web sites and applications. The audit is easy when you’re using widgets or integrate Google products such as Calendar and Docs into your site or application. Nonetheless, several Google services can fly under the radar if you don’t know where to look. You can make quick work out of trying to find these services by using a browser plugin such as NoScript or Privacy Badger to find any of the domain URLs listed under the Cookies section in Google’s Privacy and Terms site. Any of the domains listed there have the potential to collect user data.

Next, determine the collection and processing of user data. If you are integrating Google Products into your application or website, examine the privacy and security policies on the Google Product Privacy Guide. APIs are another matter. Some services are good in documenting what they do with user data – for example, Google Fonts has documentation that states that they do not collect personal data. Other times, Google doesn’t explicitly state what they are collecting or processing for some of its API services. Your best bet is to start at the Google APIs Terms of Service page if you cannot find a separate policy or terms of service page for a specific API service. There are two sections, in particular, to pay attention to:

  • In Section 3: Your API Clients, Google states that they may monitor API use for quality, improvement of services, and verify that you are compliant within the terms of use.
  • In Section 5: Content, use of the API grants Google the “perpetual, irrevocable, worldwide, sublicensable, royalty-free, and non-exclusive license to Use content submitted, posted, or displayed to or from the APIs”. While not exclusively a privacy concern, it is worth knowing if you are passing personal information through the API.

All of that sounds like using any Google service means that user tracking is going to happen no matter what you do. For the most part, that is a possibility. You can find alternatives to Google Products such as Calendar and Maps, but what about APIs and other services? Some of the APIs hosted by Google can be hosted on your server. Take a look at the Hosted Libraries page. Is your site or application using any libraries on the list? You can install those libraries on your server from the various home sites listed on the page. Your site or application might be a smidge slower, but that slight slowness is worth it when protecting user privacy.

Thank you to subscriber Bobbi Fox for the topic suggestion!