WordPress Contributors Propose Blocking FLoC in Core

WordPress contributors are proposing the project take an active position on Google’s Federated Learning of Cohorts (FLoC). This particular mechanism is Google’s alternative to third-party cookies that doesn’t require collecting users’ browsing history. The GitHub repository for FLoC explains how Google will group people together and label them using machine learning:

We plan to explore ways in which a browser can group together people with similar browsing habits, so that ad tech companies can observe the habits of large groups instead of the activity of individuals. Ad targeting could then be partly based on what group the person falls into.

Browsers would need a way to form clusters that are both useful and private: Useful by collecting people with similar enough interests and producing labels suitable for machine learning, and private by forming large clusters that don’t reveal information that’s too personal, when the clusters are created, or when they are used.

WordPress contributors are proposing blocking FLoC in core, citing the Electronic Frontier Foundation’s article titled “Google’s FLoC Is a Terrible Idea.”

“WordPress powers approximately 41% of the web – and this community can help combat racism, sexism, anti-LGBTQ+ discrimination and discrimination against those with mental illness with a few lines of code,” the proposal states.

One of the more controversial aspects of the original proposal was that it was spectacularly miscategorized as a security concern, clouding the issue at hand. It identified FLoC as a security issue for the sake of getting it into core on a more aggressive timeline, which was outlined as follows:

1. Include the patch the next minor release, rather than waiting for the next major release;
2. Back-port the patch to previous versions of WordPress.

The proposal was later revised to clarify that treating FLoC like a security concern referenced only the timeline of accelerated development and back-porting.

Although blocking FLoC seemed to have wide support in the comments on the post, the premature suggestion of treating it as a security concern weakened the proposal.

WordPress core committer Ryan McCue said that while he is in agreement with the overall sentiment, rolling it out like a security updatet would abuse users’ trust in automatic updates:

The implicit contract with users for security autoupdates is that they are used in order to protect the user from their site (data or codebase) being compromised imminently. This isn’t the case with FLoC, and may in some cases damage the site’s behaviour.

More concretely: as someone who operates a hosting service where we keep users up-to-date with security patches, this changes our approach substantially. Right now, we can confidently roll out security updates trusting the update has minimal effect outside of purely security changes, but breaching that barrier means that now scrutiny needs to be applied to every security update in order to avoid rolling out potentially breaking changes to our clients.

That erosion of trust would ultimately hurt WP’s users.

M

The proposal has started an active discussion with more than 100 commenters, including participation from the Chrome DevRel team who added more context on the current status of the experiment.

“It’s also worth noting that because this is an origin trial it means that nothing is set in stone — this is an experiment to gather feedback,” Chrome Developer lead Rowan Merewood said. “The API may change, the opt-out mechanism may change, the eligibility criteria may change. Any code changes relating to an origin trial should also be treated as temporary and experimental.”

Those who were critical of the proposal consider FLoC a personal privacy issue that is not WordPress’ problem to solve. Others believe a proposal to block FLoC is reactionary at this point, since Google has not yet finalized its FLoC experiment.

“Thinking about users… i.e. the readers of a blog, they deserve choice,” Andy Beard commented.

“They can choose which browser they use.
“They can choose settings in the browser.
“They can choose some overall options on a Google privacy site.
“They can install a multitude of plugins.

“Alternatively, if WordPress blocks FLoC by default, that actually removes a choice – the choice of a user to see more relevant advertising.”

Several participants in the discussion were opposed to FLoC but also not supportive of a WordPress core effort to block it.

“While I’m not pro-FLoC (and won’t have my browsers using it) I certainly wouldn’t expect a website to make the choice to opt-out for me, and I can’t see why the majority of WordPress users and people visiting WordPress sites would expect that either,” WordPress lead developer Dion Hulse commented.

“Perhaps more importantly, would WordPress also continue to opt out all future browser protocols too? Once you delve into blocking one, you’ve either got to block them all, or you’re playing favorites.”

Mika Epstein, who also expressed her opinion as anti-FLoC, said she is not in support of backporting a block due to the practicality of such an effort.

“If the decision is made to include this, I would support it as a filterable privacy enhancement only, not security,” Epstein said.

“That said, I do not support backporting with the precedent that we did not backport the GDPR exporting stuff. Having it exist as a plugin (there are three already) is sufficient for those who are on older versions. The undue strain of increased backporting needs to be minimized, not maximized in my opinion.”

Others commented on the harm to independent publishers whose main source of revenue is often advertising.

WordPress lead developer Helen Hou-Sandi requested the proposal be re-written to clarify the differences between disabling FLoC on a site level vs the browser level as a consumer. She also discouraged referring to the matter as a security issue and recommended the proposal’s proponents justify the work required to backport the block. Hou-Sandi recommended opening a trac ticket as a more appropriate avenue of discussion regarding core implementation and inclusion, as contributors have not yet reached a consensus.

The topic will be up for discussion at the next core developers’ chat on Wednesday, April 21, 2021.