Posted on

AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives

The Chrome Dev Summit concluded earlier this week. Announcements and discussions on hot topics impacting the greater web community at the event included Google’s Privacy Sandbox initiative, improvements to Core Web Vitals and performance tools, and new APIs for Progressive Web Apps (PWAs).  

Paul Kinlan, Lead for Chrome Developer Relations, highlighted the latest product updates on the Chromium blog, what he identified as Google’s “vision for the web’s future and examples of best-in-class web experiences.”

During an (AMA) live Q&A session with Chrome Leadership, ex-AMP Advisory Board member Jeremy Keith asked a question that echoes the sentiments of developers and publishers all over the world who are viewing Google’s leadership and initiatives with more skepticism:

Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?

The question drew a tepid response from Chrome leadership who avoided giving a straight answer. Ben Galbraith fielded the question, saying he could not comment on the AMP-related legal proceedings but focused on the Privacy Sandbox:

I think it’s important to note that we’re not asking for blind trust with the Sandbox effort. Instead, we’re working in the open, which means that we’re sharing our ideas while they are in an early phase. We’re sharing specific API proposals, and then we’re sharing our code out in the open and running experiments in the open. In this process we’re also working really closely with industry regulators. You may have seen the agreement that we announced earlier this year jointly with the UK’s CMA, and we have a bunch of industry collaborators with us. We’ll continue to be very transparent moving forward, both in terms of how the Sandbox works and its resulting privacy properties. We expect the effort will be judged on that basis.

FLoC continues to be a controversial initiative, opposed by many major tech organizations. A group of like-minded WordPress contributors proposed blocking Google’s initiative earlier this year. Privacy advocates do not believe FLoC to be a compelling alternative to the surveillance business model currently used by the advertising industry. Instead, they see it as an invitation to cede more control of ad tech to Google.

Galbraith’s statement conflicts with the company’s actions earlier this year when Google said the team does not intend to disclose any of the private feedback received during FLoC’s origin trial, which was criticized as a lack of transparency.

Despite the developer community’s waning trust in the company, Google continues to aggressively advocate for a number of controversial initiatives, even after some of them have landed the company in legal trouble. Google employees are not permitted to talk about the antitrust lawsuit and seem eager to distance themselves from the proceedings.

Jeremy Keith’s question referencing the AMP allegations in the recently unredacted antitrust complaint against Google was extremely unlikely to receive an adequate response from the Chrome Leadership team, but the mere act of asking is a public reminder of the trust Google has willfully eroded in pushing AMP on publishers.

When Google received a demand for a trove of documents from the Department of Justice as part of the pre-trial process, the company was reluctant to hand them over. These documents reveal how Google identified header bidding as an “existential threat” and detail how AMP was used as a tool to impede header bidding.

The complaint alleges that “Google ad server employees met with AMP employees to strategize about using AMP to impede header bidding, addressing in particular how much pressure publishers and advertisers would tolerate.”

In summary, it claims that Google falsely told publishers that adopting AMP would enhance load times, even though the company’s employees knew that it only improved the “median of performance” and actually loaded slower than some speed optimization techniques publishers had been using. It alleges that AMP pages brought 40% less revenue to publishers. The complaint states that AMP’s speed benefits “were also at least partly a result of Google’s throttling. Google throttles the load time of non-AMP ads by giving them artificial one-second delays in order to give Google AMP a ‘nice comparative boost.‘”

Although the internal documents were not published alongside the unredacted complaint, these are heavy claims for the Department of Justice to float against Google if the documents didn’t fully substantiate them.

The AMP-related allegations are egregious and demand a truly transparent answer. We all watched as Google used its weight to force publishers both small and large to adopt its framework or forego mobile traffic and placement in the Top Stories carousel. This came at an enormous cost to publishers who were unwilling to adopt AMP.

Barry Adams, one of the most vocal critics of the AMP project, demonstrated this cost to publishers in a graph that shows the percentage of articles in Google’s mobile Top Stories carousel in the US that are not AMP articles. When Google stopped requiring AMP for the mobile Top Stories in July 2021, there was a sharp spike in non-AMP URLs being included.

Once AMP was no longer required and publishers could use any technology to rank in Top Stories, the percentage of non-AMP pages increased significantly to double digits, where it remains today. Adams’ article calls on the web community to recognize the damage Google did in giving AMP pages preferential treatment:

“But I’m angry. Because it means that for more than five long years, when AMP was a mobile Top Stories requirement, Google penalised these publishers for not using AMP.

There was no other reason for Google to stop ranking these publishers in their mobile Top Stories carousel. As is evident from the surge of non-AMP articles, there are likely hundreds – if not thousands – of publishers who ticked every single ranking box that Google demanded; quality news content, easily crawlable and indexable technology stack, good editorial authority signals, and so on.

But they didn’t use AMP. So Google didn’t rank them. Think for a moment about the cost of that.”

Even the publishers who adopted AMP struggled to get ad views. In 2017, Digiday reported on how many publishers have experienced decreased revenues associated with ads loading much slower than the actual content. I don’t think anyone at the time imagined that Google was throttling the non-AMP ads.

“The aim of AMP is to load content first and ads second,” a Google spokesperson told Digiday. “But we are working on making ads faster. It takes quite a bit of the ecosystem to get on board with the notion that speed is important for ads, just as it is for content.”

This is why Google is rapidly losing publishers’ trust. For years the company encumbered already struggling news organizations with the requirement of AMP. The DOJ’s detailed description of how AMP was used as a vehicle for anticompetitive practices simply rubs salt in the wound after what publishers have been through in expending resources to support AMP versions of their websites.

Automattic Denies Prior Knowledge of Google Throttling Non-Amp Ads

In 2016, Automattic, one of the most influential companies in the WordPress ecosystem, partnered with Google to promote AMP as an early adopter. WordPress.com added AMP support and Automattic built the first versions of the AMP plugin for self-hosted WordPress sites. The company has played a significant role in driving AMP adoption forward, giving it an entrance into the WordPress ecosystem.

How much did Automattic know when it partnered with Google in the initial AMP rollout? I asked the company what the precise nature of its relationship with Google is regarding AMP at this time.

“As part of our mission to make the web a better place, we are always testing new technologies including AMP,” an official spokesperson for Automattic said.

This may be true but Automattic has done more than simply test the new technology. In partnering with Google, it has been instrumental in making AMP easier for WordPress users to adopt.

“We received no funds from Google for the project,” a spokesperson for Automattic said when asked if the company was compensated as a partner in this effort.

What did Google promise Automattic to convince the company to become an early partner in the AMP rollout? I asked if the company has an official response to the allegations that Google was throttling the load time of non-AMP ads by giving them artificial one-second delays in order to give Google AMP “a nice comparative boost.” The spokesperson would not respond to the specific claims but indicated the company did not have prior knowledge of any actions that might not be above board:

We chose to partner with Google because we believed that we had a shared vision of advancing the open web. Additionally, we wanted to offer the benefit of the latest technology to WordPress users and publishers including AMP.

While we aren’t able to comment on legal matters in progress, we can say that over the course of our partnership, we were not aware of any actions that did not align with our company’s mission to support the open web and make it a better place.


The antitrust complaint also details a Project NERA, which was designed to “successfully mimic a walled garden across the open web.” When asked about this, Automattic reiterated its commitment to supporting the open web and gave the same response: “We were not aware of any actions that did not align with our company’s mission.”

In examining the weight of the DOJ’s allegations, it’s important to consider how this impacts WordPress as a CMS that is used by 42% of the web. A new performance team for WordPress core is being spearheaded by Yoast and Google-sponsored employees. The initial proposal is to improve core performance as measured by Google’s Core Web Vitals metrics. These metrics are a set of specific factors that Google deems important for user experience.

Without questioning the personal integrity of the contributors on that team, I think it’s important that Google leadership acknowledge how AMP has damaged publishers’ trust in light of recent events. Many of these contributors are heavily involved in building AMP-related resources for the WordPress ecosystem. Are their contributions purely aimed at making WordPress core more performant or is there a long game that serves Google’s interests being woven into this initiative? Would these employees even be aware of it if there were?

These are important considerations if Google defines the performance metrics WordPress is measuring against. The company’s alleged misdeeds seem to be buried high up in the command chain. Those tasked with peddling AMP may have had no knowledge of the alleged anticompetitive practices identified by the DOJ in Google’s internal documents. The WordPress community should continue to be vigilant on behalf of publishers who depend on WordPress to remain an unadulterated advocate for the open web.

Posted on

Google Concludes FLoC Origin Trial, Does Not Intend to Share Feedback from Participants

Google quietly concluded its FLoC (Federated Learning of Cohorts) origin trial this week. The trial was part of Google’s Privacy Sandbox initiative, a suite of new technologies designed to replace third-party cookies, fingerprinting, and other commonly-used tracking mechanisms. This particular experiment groups people together based on browsing habits and labels them using machine learning.

FLoC’s trial was scheduled to end Jul 13, 2021, and Google has decided to remove the project from the testing phase while analyzing feedback.

“We’ve decided not to extend this initial Origin Trial,” Google senior software engineer Josh Karlin said in thread on Chromium’s Blink Developers group forum. “Instead, we’re hard at work on improving FLoC to incorporate the feedback we’ve heard from the community before advancing to further ecosystem testing.”

The controversial experiment has been met with opposition from privacy advocates like makers of the Brave browser and EFF who do not perceive FLoC to be a compelling alternative to the surveillance business model currently used by the advertising industry. Amazon, GitHub, Firefox, Vivaldi, Drupal, Joomla, DuckDuckGo, and other major tech companies and open source projects have already opted to block FLoC by default.

So far, Twitter has been the first major online platform that appears to be on board with FLoC after references to it were recently discovered in the app’s source code.

Google’s initial efforts in presenting FLoC failed to gain broad support, which may have contributed to the company putting the brakes on its plan to phase out third-party cookies in Chrome by 2022. As the advertising industry yields to pressure from the last few years of privacy legislation, third-party cookies will be on their way out in what is colloquially known as the “Cookie Apocalypse.” Google has postponed this milestone for Chrome to begin in mid-2023 and end in late 2023. 

“We need to move at a responsible pace,” Chrome Privacy Engineering Director Vinay Goel said. “This will allow sufficient time for public discussion on the right solutions, continued engagement with regulators, and for publishers and the advertising industry to migrate their services. This is important to avoid jeopardizing the business models of many web publishers which support freely available content.”

Discussion on a proposal for WordPress to block FLoC has stalled in Trac but may have been premature in the first place if FLoC doesn’t end making it to further testing. Proponents of blocking FLoC saw WordPress’ support or opposition as critical to the success or failure of FLoC adoption on the web.

A recent article on the WordPress.com VIP blog titled “Goodbye, Third-Party Cookies, Hello Google’s FloC,” indicates that Automattic may be straddling the fence on the controversial new technology:

FLoC has its plus points. But it isn’t as privacy-focused as we would like, and can lead to discriminatory practices, as described above. Then there’s the concern of letting Google dominate yet another aspect of tech. Google also plans to charge any third-party tracking company for use of any of the data it has collected.

For the time being, it looks like major tech platforms are off the hook for taking an active position on FLoC since it has been sent back for major modifications. In the most recently updated timeline for Privacy Sandbox milestones, Vinay Goel said Google received “substantial feedback from the web community during the origin trial for the first version of FLoC.”

At the conclusion of its origin trial, FLoC seems far from ready for adoption, having failed to gain a foothold in the industry. The concern is that Google may ram FLoC through anyway using the weight of Chrome’s market share, despite the web community’s chilly reception. Although these proposed changes to ad tech will impact the entire industry, as well as regular internet users, Google does not intend to disclose any of the private feedback the company received during FLoC’s origin trial.

“The main summary of that feedback will be the next version, and you can surmise based on what features (and the reasoning for these changes) are available in the next version,” Google mathematician Michael Kleber said during a recent Web Commerce Interest Group (WCIG) meeting. 

Privacy advocates want to see more transparency incorporated into this process so that major concerns are not left unaddressed, instead of leaving it to stakeholders across the web to try to deduce what Google has solved in the next version of FLoC. Overhauling the advertising industry with new technologies should be done in the open if these changes are truly intended to protect people’s privacy.

Posted on

Chrome Canary Adds Flag for Disabling FLoC Testing

Google’s controversial Federated Learning of Cohorts (FLoC) experiment now has a feature flag within Chrome Canary (the nightly build of Chrome for developers) that allows users to opt out.

In January 2020, Google announced its plans to discontinue support for third-party cookies in Chrome within two years. The first bits and pieces of the company’s Privacy Sandbox initiative started landing in Chrome in December 2020 with an initial flag to disable it. FLoC, Google’s proposed replacement for third-party cookies, began testing as a developer origin trial in Chrome at the end of March 2021.

In Canary, users can navigate to chrome://flags/#privacy-sandbox-settings-2 to find the Privacy Sandbox Settings 2 flag.

Relaunch Canary to save the changes. This will unlock the box that allows users to either reset their FLoC group or opt out of FLoC entirely. The new setting is available under chrome://settings/privacySandbox:

If the setting remains enabled, which is the default, Chrome will group users into cohorts based on recent browsing activity and then advertisers select ads for the entire group. Browsing activity for the individual is “kept private on your device,” but Chrome certainly has access that information by way of mediating the cohorts. Google notes that the trial is currently only active in some regions.

Users can also opt out of Privacy Sandbox trials on the same page. Current trials include the following:

  • Advertisers and publishers can use FLoC
  • Advertisers and publishers can study the effectiveness of ads in a way that does not track you across sites

Google has not specified how users would opt out of FLoC if the experiment is successful and moves forward. Organizations and site owners who are currently on the fence about it may go either way depending on how easy it is for Chrome users to opt out themselves.

“Instead of comparing FLoC to its predecessor, third party cookies, I feel it’s actually more like the Facebook Pixel – mostly in the sense that it’s controlled by a single surveillance capital company,” WordPress core contributor Roy Tanck commented on the trac ticket for the discussion. “FLoC may not be quite as nefarious, but I feel it should be something website owners consciously opt into.

“WordPress has always advocated for a free and open web, and FLoC appears to actively harm that goal. I think WordPress should take a stand against this, and do it now.”

A few others have chimed in on the ticket recently as other open source projects have started blocking FLoC by default. Plugin developer David McCan’s comment referenced analytics data published in early May suggesting that US users choose to opt out of tracking 96 percent of the time following the changes in iOS 14.5.

“There is no doubt that coming down on the side of user privacy vs user tracking is the right thing to do,” McCan said. “Which headline would we rather see? ‘By default millions of WordPress websites are allowing users to be tracked’ or ‘WordPress takes steps to block user tracking making millions of websites around the world safe to visit?’

“We already have a policy that opt-in by default tracking’ is not allowed in plugins hosted by WordPress. This is because we recognize the responsibility and benefit of protecting user privacy.”

During a live marketing event Google hosted at the end of last week, Jerry Dischler, vice president and general manager of Ads, addressed the recent privacy concerns surrounding FLoC.

“We’ll be using these [Privacy Sandbox] APIs for our own ads and measurement products just like everyone else, and we will not build any backdoors for ourselves,” Dischler said.

Dischler also reaffirmed Google’s commitment to moving away from third-party cookies.

“Third-party cookies and other proposed identifiers that some in the industry are advocating for do not meet the rising expectations consumers have when it comes to privacy,” he said. “They will not stand up to rapidly evolving regulatory restrictions; they simply cannot be relied on in the long term.”

Google bears the burden of reassuring advertisers that effective advertising is still possible as the company moves beyond tracking cookies. It is aiming to future-proof advertisers’ measurement of campaign performance with what it claims are “privacy-safe solutions.” The company is pushing hard for advertisers to adopt these new techniques, promising more actionable first-party conversion data.

Although consumer expectations have changed, FLoC may not be the answer to the need for a privacy-preserving advertising model. So far it looks like Google will have an uphill battle to gain more broad support from browsers, advertisers, and consumers.

Posted on

Joomla Blocks FLoC by Default, Drupal Moves to Block FLoC in Upcoming 9.2 Release

Joomla has announced plans to block Google’s Federated Learning of Cohorts (FLoC) by default going forward. The 3.9.2.7 security update, released yesterday, added a Permissions Policy header to disable FLoC. Users can now find a new setting in Global configuration on the Site tab in the Site Settings area, where they can toggle FLoC on if desired. This change will also affect existing sites updated from older versions.

The Joomla Developer Network blog outlined a few concerns contributors have about fingerprinting, the technology Google uses to gather information from a user’s browser to create a unique, stable identifier. They also highlighted cross-content exposure as another concern:

The technology will share new personal data with trackers who can already identify users. For FLoC to be useful to advertisers, a user’s cohort will necessarily reveal information about their behavior.
This means every site you visit will have a good idea about what kind of person you are on first contact, without having to do the work of tracking you across the web.
If you visit a site to buy a jumper they will have access to your cohort identifying number. This could also give them your political thinking or reveal that you are also in certain defined medical groups. There is nothing to stop these groups being backward engineered and your movement between the cohorts will reveal a lot about you over time.

A similar permissions policy header was added to Drupal 9.2.0-beta1 on May 14, after a lengthy discussion with overwhelming consensus to block FLoC. It is expected to be part of Drupal core on June 16, 2021, when 9.2 is scheduled to be released.

“I’d love to see this added to core and enabled by default,” Drupal founder Dries Buytaert commented on the implementation discussion. “We should provide an option/mechanism to disable it though.” He said he has already added a Permissions-Policy header on his personal blog.

Drupal makes disabling it a bit more of a hurdle than Joomla, as it requires setting block_interest_cohort to FALSE in the settings.php file.

Although FLoC is still in the experimental stage, many other frameworks and tools have blocked it or are planning to block it. The DuckDuckGo Chrome extension has been reconfigured to block FLoC’s tracking, in addition to DuckDuckGo Search opting users out. GitHub is also blocking FLoC on GitHub Pages and all sites served from the github.io domain. Although Chrome is the market leader by a wide margin, Google has not yet been able to sway any other major browsers to get on board. At this time, Microsoft Edge, Safari, and Firefox do not plan to adopt FLoC.

“It is disappointing to see Google, instead of taking the present opportunity to help design and build a user-first, privacy-first Web, proposing and immediately shipping in Chrome a set of smaller, ad-tech-conserving changes, which explicitly prioritize maintaining the structure of the Web advertising ecosystem as Google sees it,” Brave CEO and co-founder Brendon Eich and senior privacy researcher Peter Snyder wrote in a statement on the company’s blog. “The worst aspect of FLoC is that it materially harms user privacy, under the guise of being privacy-friendly.”

Brave has disabled FLoC and the company recommends that all sites do the same, advising that “any new privacy-risking features on the web should be opt-in.” The post concludes that FLoC will not be an improvement on current ad tech:

Overall, FLoC, along with many other elements of Google’s “Privacy Sandbox” proposal, are a step backward from more fundamental, privacy-and-user focused changes the Web needs. Instead of deep change to enforce real privacy and to eliminate conflicts of interest, Google is proposing Titanic-level deckchair-shuffling that largely maintains the current, harmful, inefficient system the Web has evolved into, a system that has been disastrous for the Web, users and publishers.

What the Web desperately needs is radical change, one where “would users want this?” is the most important question asked for each new feature. Instead, FLoC and “Privacy Sandbox” ask “how can we make this work for ad-tech, in a way that users will tolerate or not notice.”

The open source Umbraco CMS is taking a more hands-off approach to the controversial issue. In response to a PR suggesting suggesting Umbraco block FLoC, Umbraco project manager Sebastiaan Janssen said, “We feel it’s not our place or task to enforce this kind of blocking, we believe site implementers should be free to use whatever services they think make sense for their sites (as well as block them when they want).”

At this point in Google’s Chrome’s Origin Trial, Chrome representatives do not yet know how the FLoC API will be finalized for determining which pages will be included in FLoC calculations. WordPress has not yet made a determination about whether to block FLoC or leave it site owners to decide. Multiple FLoC blocking plugins are already available to users who want to opt out now. After a lengthy and heated discussion on a proposal to block FLoC by default, WordPress core leadership moved the conversation to Trac where contributors are monitoring Google’s experiment.

The ticket has not yet received much feedback as WordPress is taking a more cautious approach that will depend on how Google decides to implement its FLoC API. Without the support of any major browsers, WordPress’ support or opposition may be critical to the success or failure of FLoC adoption on the web. Once more information from the FLoC trial becomes available, WordPress contributors will be in a better position to decide a course of action.

Posted on

FLoC Blocking Discussion Continues on WordPress Trac

Last week WordPress contributors began a heated discussion regarding blocking FLoC (Federated Learning of Cohorts). Google’s experimental alternative to third-party cookies has become a highly contentious topic that made its way into last week’s Core developers meeting.

Representatives from the Chrome team also attended the meeting to clear up any confusion and answer questions about how FLoC currently works. They related that during the FLoC Origin Trial (the process by which Chrome introduces new proposed API’s for feedback from developers), a page will only be included in the browser’s FLoC computation for one of two reasons:

“In the final end state, we expect the way FLoC will work is that the only pages that will be relevant to calculating your cohort are the pages that call the FLoC API,” Chrome representative Michael Kleber said. “So pages will ‘opt in’ by using some new JS function call.”

Since FLoC is still in the the beginning stages, the Chrome team cannot confirm the final behavior for what pages will be included in FLoC calculations. At this point, it seems like it will primarily affect publishers and ad-supported websites in the future.

Although the authors and proponents of the proposal prescribed immediate action, WordPress’ leadership has determined that an implementation discussion is premature at this time.

“I am now amending my posted request for a reworking of the proposal – I do not want to see another proposal for action in WordPress right now,” WordPress lead developer Helen Hou-Sandí said during the meeting. “What we need is a Trac ticket where we track the status of the FLoC trial/implementation and discuss periodically to see if action is needed. I have an opinion, but it’s not really relevant at this time, and I think more of us should be comfortable with that idea.”

The Chrome team did not expect that many people would be considering FLoC at this point, as Origin Trials generally only attract a handful of people who are curious about the technical details. FLoC gained more widespread attention after the critical article from EFF. The original proposal on make.wordpress.org also attracted media attention due to its confusing approach, premature assumptions, and lack of critical peer review.

Peter Wilson commented on behalf of WordPress’ security team after meeting to discuss the issue, stating that it is unequivocally not a security concern:

Treating this as WordPress currently treats any other security issue would require releasing 21 versions of WordPress. As identified in other comments on this thread, it would also break the implicit contract of security releases by including an enhancement in the release.

As a result of these consideration, the security team have concluded that treating this as a security issue is inappropriate.

Whether this is suitable to be included in WordPress and subsequently released as part of the next 5.7.x maintenance release are discussions for the Core team. The security team do not have a consensus view on these questions.

Hou-Sandí opened a ticket where discussion continues on the implications of FLoC. As more information becomes available from Chrome’s Origin Trial, WordPress contributors will be better prepared to discuss how it may affect publishers and whether a core block, privacy setting, or other action is necessary.

Posted on

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.

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. Representatives from the Chrome team will also be attending to answer any questions about FLoC.