Proposal: Treat FLoC like a security concern

Treat FLoC like a security concern – Make WordPress Core

Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser.

TL;DR: FLoC places people in groups based on their browsing habits to target advertising.

Why is this bad? As the Electronic Frontier Foundation explains in their post “Google’s FLoC is a terrible idea“, placing people in groups based on their browsing habits is likely to facilitate employment, housing and other types of discrimination, as well as predatory targeting of unsophisticated consumers.

This is in addition to the privacy concerns of tracking people and sharing their data, seemingly without informed consent – and making it more difficult for legislators and regulators to protect people.

So What Now?

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:

function disable_floc( array $headers ) : array {

$permissions = [];

if ( ! empty( $headers['Permissions-Policy'] ) ) {

// Abort if cohorts has already been added.

if ( strpos( $headers['Permissions-Policy'], 'interest-cohort' ) !== false ) {

return $headers;

}

$permissions = explode( ',', $headers['Permissions-Policy'] );

}

$permissions[] = 'interest-cohort=()';

$headers['Permissions-Policy'] = implode( ',', $permissions );

return $headers;

}

add_filter( 'wp_headers', 'disable_floc' );

What About Admins Who Want FLoC?

Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filter in Core.

When balancing the stakeholder interests, the needs of website administrators who are not even aware that this is something that they need to mitigate – and the interests of the users and visitors to those sites, is simply more compelling.

Furthermore, for WordPress versions that support privacy settings, we can easily add an on-off toggle to enable websites to opt in. This would only require a few more lines of code and only a couple of new strings.

What Do You Mean By “Treat It Like A Security Concern”?

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

Why Treat It That Way? Why Not Just Wait For The Next Major Release?

Well, keep your eyes peeled, because there is a ticket for future releases on its way!

While it is indeed unusual to treat a new “feature” this way, there is precedent in that something that was not strictly a security vulnerability in comments was back-ported to previous versions for the good of the community as a whole.

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

Furthermore, a significant number of WordPress sites only update to minor versions. By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.

Request For Comment

Please join the discussion below!

Whether want to show support, disagree vehemently, or just want to make the implementation the best that it can possibly be, please have your voice be heard.

I’m aware that there is a lot of discussion on other platforms, including Twitter on this matter, but we won’t see all of it, so in addition to spreading the conversation there, please comment here too, so that it can be considered when this is discussed at development meetings and when the ticket is created (consensus building first – and that is done here )

YOU DO NOT HAVE TO BE A DEVELOPER TO PARTICIPATE. There will be a ticket on core.trac.wordpress.org where we will discuss all of the technical stuff. I’m tremendously grateful that there are so many developers, Core, Meta and others, around, but blog posts on make.wordpress.org are the places that are accessible to techies and non-techies alike

Version Control:
1. Edited to add clarification that treatment like a security concern refers to the process / procedure (accelerated development and back-porting).
2. Code snippet updated based on suggestions below. Thank you to Tom for the snippet and to everyone who suggested conditionally appending, rather than replacing.
Added some more info to the Request for Comment.

#core-privacy

Hide Comments

Follow up from April 21 dev chat: for the moment, discussion about when and how to implement are ahead of where both WordPress and FLoC actually are. I have opened a Trac ticket to monitor and discuss the issue, it is milestoned for 5.8 to ensure that it remains on the radar but if information and consensus evolve rapidly we can certainly come back to shaping a proposal around minor release inclusion. See #53069

Top comment
View in context

The suggestion of this policy as a security concern is exactly what should happen. I would be happy to provide a core patch if that would help further this effort. With 40% of the web WordPress has a responsibility to act to protect those who use the sites it is built on. This will go a long way to helping ensure that responsibility is fulfilled.

100%. WordPress should be taking an Apple like stance on privacy with this.

I agree with Chris. We have a rare opportunity to shape the web for good here!

Absolutely agree. Privacy is the sort of thing we should take a lead in.

It has absolutely nothing to do with security. I am very disappointed in the activism I see in the replies.

Especially since it’s still in limited and opt-in trial phase. We don’t know how it will look like, what changes will be made and what privacy controls will be available IF it goes through.

There are already proposals for simple ON/OFF toggle Chrome for FLoC.

Disabling monetization on millions of websites is dangerous to independent publishing.

The CHOICE should be always on consumers and hosts. Not on CMS.

Disabling something in disguise of “security” is taking away the CHOICE people should have.

Genuine questions:

Would it be okay if conservatives never even see job ads for developers at traditionally liberal multi-nationals?
What is your opinion with regards to algorithmic “shadow-banning” of independent content?

And one more…
You’re probably using a plugin to connect you to Google Adsense, right? Or one that connects you to Google Analytics, maybe?
Why would it be an undue burden to expect those plugins to override the filter, which would allow you (who actually wants to) to opt in to FLoC? As opposed to opting everybody else in, whether they want it or not, because it is what you want?

One is status quo that gives power to consumers and hosts and your proposal is value-based interference on CMS level.

So, the same question could be asked of you. Why should 40% of websites be automatically opted-out on CMS level via falsely masked security update? Is it because YOU want it that way?

I am not going to answer your questions because I can admit that right now I don’t know all the answers relating to FLoC. And the truth is, neither do you.

You are free to make these emotionally charged hypothetical questions, but until FLoC is done with its trial and we have an access to all the data and how the cohorts actually work in real life, then all these arguments are baseless.

If you truly, truly want to make that change to WP, propose it when FLoC is officially “in the wild” with all the data confirming your worries. Not when we know nothing apart from always changing documentation.

100% agree. protecting user privacy has to be in place.

This is exactly why we have published a plugin for that:
https://wordpress.org/plugins/wpm-floc/

But: Considering the plethora of edge cases and differing systems the code to provide a FLoC Opt-Out is a bit more complicated than written above, especially considering the vast amount of caching and hosting solutions that modify HTTP headers.

As a community member I would like to raise awareness about this topic, the FLoC project itself and its dangers and shortcomings.

Hallos

I actually had a look at your plugin, because we were chatting about whether it would be better to try to get your permission to just merge into Core, or to go the ticket-and-patch route.

One of the things that I noticed is that your plugin included and call up JavaScript files. Would you mind providing me with a little bit of background about why you chose to go this route?
I do understand that various server-environments can impact the implementation, however, as I understand it, the directive is ultimately provided as part of the header, and as Core is able to modify header content, I do believe that this should be possible to implement within Core?

The JavaScript file in the plugin provides a little check to see if the FLoC deactivation header is really present in the frontend.

Especially in complicated hosting situation this can not be taken for granted, as the ‘Permissions-Policy’ HTTP header is relatively new.

So adding HTTP Headers for non-technical applications is something we have never done before and will likely break in some configurations leaving users open to tracking without their knowledge, if there is no test or feedback.

I’m totally in favour of this as a feature.

I feel it’s a bigger piece of work then it would intially appear:

It needs to check for presence of existing `permisson-policy` headers for starters.

My bigger concern is while I agree it’s a good idea it needs to be easy to opt out (or rather opt back in) and this has to be available in user accessible way. The obvious solution would be to use the existing privacy controls, and screens as mentioned in the proposal.

However this then EXCLUDES the ability to backport. Making it a filter while this would allow backporting is the WP equivilent of hiding the permissions in HTTP headers for browsers.

I think that having the feature is worthwhile development even for just the current version.

Beyond the practical my second issue for not backporting is that adding a feature blurs the line even more so then it has before, even for a valuable feature as this, but where would it stop, should we backport Gutenberg? (obviously not, but you get the point). The counter argument is the line has been crossed before, and it opened a can of worms that wasn’t solved.

If I had one priority preserving the trust in the automatic update system, trumps introducing even genuinely important features. We can educate people about new features if they are willing to listen.

TLDR;
Love the feature idea, it will need work. Practically it won’t be easy to back port, it has potential to damage the trust in automatic updates.

Bring the feature into core on the next minor update with a UI and help show the world WordPress is serious about privacy.

Hallo!

I believe that the main reason why we should not back-port, is that we should not change the status quo on users unexpectedly.
However, here it is not us that is changing the status quo (as would be the case with back-porting Gutenberg, for example). We would be maintaining the status quo, particularly for non-technical website owners, who may not even be aware that a thing like FLoC exists.

That having been said, the fact that the privacy settings are relatively new is a concern that I share with you.
I have been giving it some thought – and the “discourage search engines” setting in WordPress (which is used to place a do-not-crawl directive and to disable sitemaps) is MUCH older. If we place the setting here instead, I believe this would mitigate some of this concern?

Kill it before it lays eggs. I don’t like it when Google follows me around the web, let alone read my entire browser history. Even though that data won’t be leaked to Google verbatim, it will harm non-tech savvies and unwelcomely advance fingerprinting.

Those who want it enabled on their site can install an ad widget/block plugin that adds the option “Track using FLoC.”

As a user and a privacy aware developer and admin, this suggestion has my support.

While I agree that it should be easy to opt back in, I support adding the opt-out header by default.

It makes sense to treat it as a security, matter. And, in principle, I agree with @roytanck that it should add the opt-out header by default, but seeing there is (kinda) a tradition in WordPress to let the user decide and if it is not opt-out by default, WP should highlight this issue and present it in a very clear noticeable… notice when the update is released and a very clear help message in the settings pages in the future versions.

Thoroughly support. WordPress is all about owning our own platforms and opt-out tracking is the antithesis of this. An opt-in in the Privacy settings would be great.

Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filter in Core.

I would argue the opposite, those websites who want to block FLoC are likely to have the technical know-how to add in the header and disable it. If someone has heard of FLoC and knows enough about it to want to block it, they’re likely already some what tech savvy. Where do we draw the line at what WordPress should be blocking in core for privacy? Will we stop allowing all of Google’s current third party tracking cookies? Should WordPress block ALL third party tracking cookies like Facebook too? I would be very surprised in everyone commenting so far here about this privacy setting doesn’t have a Facebook, Twitter, or both. Both of those companies track and know infinitely more about you already, and yet you still use their platforms. If people are this passionate about blocking FLoC they should also be as passionate about all privacy and not be supporting and using platforms which don’t respect (and even abuse) your privacy in many ways. I support educating users on what FLoC is and its pros / cons, and making sure it’s easy to have ways to disable it. But calling it a “Security concern” is just absolutely false and sets a dangerous precedent for what is security, and what is privacy.

I in fact do not have a Facebook account. Something I can absolutely recommend. But that is not the point.

Third party cookies are already going away, and the last thing we need is an opaque replacement that works “95% as well” (Google’s own words).

The web currently is a tracking nightmare, and I think it aligns perfectly with WordPress’s mission and values to block intrusive technologies that have no benefit for the end user.

I manage a large number of WP sites and do not have a Facebook account, or a personal Twitter account (only one for my business). Please don’t assume things about people.

I wholeheartedly support this proposal. WP has an opportunity to choose “privacy by default” for everyone visiting a WP site who still uses Chrome.

I would argue the opposite, those websites who want to block FLoC are likely to have the technical know-how to add in the header and disable it. If someone has heard of FLoC and knows enough about it to want to block it, they’re likely already some what tech savvy.

I think arguing as a justification that either type of person would _”be likely to have the technical know-how”_ is an assertion without supporting evidence and thus should not be used as a justification for a policy.

The appropriate solution — assuming the community wants to block FLoC by default — is to provide an admin UI for blocking or allowing it, and a notification in the dashboard on upgrade that said choice was made with a link to the section of the admin UI so the site owner can turn it back on if they want to.

Another possibly better option is to add a user notice that the site is using FLoC and allow users to opt-out individually. That I could easily agree should not be something the site owner has easy control over, other than to skin it maybe.

#fwiw

We need the Consent API first to provide individual opt-in / opt-out, but this is being discussed

The unfortunate reality is that we cannot do everything at once with limited resources.
I won’t ask you to take my word for it, but there are a lot of us who are very passionate about ALL privacy, not just when it comes to FLoC.
If this is something that is important to you too, I’d like to invite you to get involved with the Disclosures Tab and the Consent API.
While those two items are much bigger / complex projects, they ultimately seek to fulfill the exact objectives you are referring to.

I think you’re falling into a straw man fallacy there. While it is true that Facebook and Twitter are tracking on third party websites, the difference is those are explicitly opted-into by the website owner. i.e. the site owner must insert javascript from Facebook or Twitter or embed an image etc to trigger those tracking activities. The FLoC is different, in that every website is immediately and implicitly opted-into contributing to the FLoC tracking unless they explicitly tell the browser not to do it.

So the hypothetical question “should we also block facebook tracking cookies?” is invalid because those are purposely put there by the site owner.

Thank you for bringing this forward.

FLoC is problematic in many ways. Users are opted in without notice. It is being tested before there are tools in place to monitor and fix issues. When those tools are in place, Google will try to fix issues with FLoC cohorts by accumulating massive amounts of data about users and then see what it thinks is being leaked and whether or not that is acceptable. It is out of people’s control. The cohort you are in can be used to identify your income bracket, political affiliations and any number of other dimensions. Cohorts will greatly increase the problem of targeting and creating information bubbles / silos for the spread of disinformation. There is a reason why every privacy conscious browser will not support it.

If a workable solution is available for the current version of WordPress but is problematic to backport immediately, I’d be in favor of implementing it in stages.

Append it to the permissions-policy header, don’t just replace the header. That’s because permissions-policy covers more than just disabling FLoC. I myself do the full monty of disabling everything:

accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=(), clipboard-read=(), clipboard-write=(), gamepad=(), speaker-selection=(), conversion-measurement=(), focus-without-user-activation=(), hid=(), idle-detection=(), serial=(), sync-script=(), trust-token-redemption=(), vertical-scroll=(), notifications=(), push=(), speaker=(), vibrate=(), interest-cohort=()

Thank you for this!
We’d like to discuss this with the Accessibility team, but I just wanted to let you know that we are reading ALL of the feedback here and that your suggestion has been noted and is being considered.
I’m just not replying to every single comment because we’d like for everyone to be heard, so I’m mainly commenting to ask for further clarification / feedback, as I do not want to monopolize this conversation.

I’m not suggesting blocking everything by default as I do, just to have the filter check:
1. if there is already a Permissions-Policy header
1.1 if interest-cohort is already in it, leave it untouched
1.2 if interest-cohort is not there, append it
2. if there is not Permissions-Policy header, just set it to interest-cohort=() as you are doing in your proposal.

The only reason I am setting Permissions-Policy is to limit the damage if for whatever unlikely reason an attacker manages to inject JavaScript into the page. I don’t rely on third-party JavaScript so the risk is minimal, but it could still be done by a malicious bookmarklet or extension.

I agree, and to that end, here is a version that in theory is more compatible:

function disable_floc( array $headers ) : array {
	$permissions = [];
	if ( ! empty( $headers['Permissions-Policy'] ) ) {
		// Abort if cohorts has already been added.
		if ( strpos( $headers['Permissions-Policy'], 'interest-cohort' ) !== false ) {
			return $headers;
		}
		$permissions = explode( ',', $headers['Permissions-Policy'] );
	}

	$permissions[] = 'interest-cohort=()';
	$headers['Permissions-Policy'] = implode( ',', $permissions );
	return $headers;
}
add_filter( 'wp_headers', 'disable_floc' );

It could be further enhanced to check for the presence of the interest-cohort to avoid duplication, or if a user want’s to enable it

:wave:
Hallo, @tjnowell
We’ve been chatting about the snippet and would just like to ask why you explode on “;” but implode on “,”?
A lot of people copied the original snippet into their posts / tweets about this – and many already added it to their websites, so I updated the proposal to include your snippet, so just want to make sure.

because when I changed ; to , I forgot to change the explode, it’s been fixed in the comment and post. A previous version of the snippet incorrectly used ;

I strongly agree that this needs to be treated as a security issue and, as always, privacy should be the default.

While I agree with the overall sentiment here, I think it is a mistake to treat this as a security update and risks abusing user trust in automatic updates. To call it a security update appears to me to be intentionally misusing the term in order to roll it out via 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.

I’m on board for the political statement of countering Chrome’s encroachment on privacy, as well as the alignment of this with WP’s values generally, but making this change as a “security” update is a step too far.

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.

I agree with this comment 100%, and I say this as someone who absolutely abhors FLoC and takes every possible measure to block/break all tracking.

Let’s absolutely build something into WordPress core to block FLoC, opt-in or opt-out, but please don’t call it a security update.

Amending my comment:

Based on all the discussion in the core meeting today with WP devs/community and members from Chrome DevRel, FLoC only triggers when the site is running ads that benefit from FLoC.

So, it seems to me that the best place for anti-FLoC measures are in the browser under control of the viewer, not in the site.

If a site is triggering FLoC in the first place, it likely intends to benefit from FLoC in some way.

While I agree with the overall sentiment here, I think it is a mistake to treat this as a security update and risks abusing user trust in automatic updates. To call it a security update appears to me to be intentionally misusing the term in order to roll it out via automatic updates.

Definitely agree with Ryan here.

All security updates might present the same risk. Sometimes software is written that depends on poor security, and it’s right that it’s deactivated. Your argument seems ill informed. Security updates can always lead to breakages in poorly designed (insecure, or insecure needing) software. Your contract with the users remains secure because right now WP has beat Chrome at the pass. If they were to wait 6, 12, 18 months then perhaps the line of thought about functionality might be correct. In any case, it is a security update for the users of that website and it’s owners, that anyone they have not opted into could track users. If I’m honest, I deferred reading this over the weekend, but it seems a relatively minor change to walk back on if you want to preserve non-site owner spying on sites.

While I agree with the overall sentiment here, I think it is a mistake to treat this as a security update and risks abusing user trust in automatic updates.

I completely agree. This is not a security update and calling it that will hurt WordPress and diminish user’s trust when a real “upgrade or lose you site” security patch comes out.

The privacy aspect is important but call it what it is and don’t misuse “security” that way.

:waves:
Hey, all
Thanks for the comments.

For clarification, which of the following do you object to?
1. Calling it a / marketing it as a security patch;
2. Including it in a minor version;
3. Backporting?

Looking forward to more discussion. Thanks, folks!

All of the above.

I’m not trying to be obtuse and I know you get that.

1. It should not be called a security patch because it is not.

No one’s WordPress installation is going to get compromised because of FLoC. Calling something distasteful a security issue is not appropriate and would hurt WordPress. After so much work has happened to improve the reputation of the platform, misusing the term should be avoided.

2. I think this should remain a plugin instead and be considered for the next major release.

I understand the privacy issue here but doing this in a minor release is akin to adding a new feature.

3. Backporting. See above my replies for items #1 and #2.

This is not a security patch so there’s no reason to backport it.Let’s not add new functionality to the base WordPress installation. I do not think it would break anything but again, new feature. Those belong in new releases.

Calling it a / marketing it as a security patch

I do not believe it should be treated as or promoted as a security patch, which is the core of the proposal here.

Including it in a minor version

WP already has a history of including potentially major features in minor versions (see the GDPR changes eg), so I don’t believe this breaks users’ trust or expectations. Ditto for autoupdates along those lines. The potential impact of the change itself is fairly minor, it’s the categorisation of the change that is an issue.

I think this would be fine to treat as a bug and hence include in a minor release, and again I think likely aligns with WP’s philosophy, although personally I don’t think it’s a bug per se.

(I would prefer we not include non-bugfix changes in minor releases, but IMO that ship has already sailed.)

Backporting?

I don’t have an opinion on backporting; we’ve backported both security fixes and bugfixes, so if this is accepted as a minor patch then I think it’s fine to backport.

I don’t think it should be called a security update (as you say, this twists the meaning of the term “security update”). But I think it should be rolled out on other grounds. It is an update that maintains the status quo that this mechanism is not used for (indirect) user tracking. Users may be surprised to find that their site has been automatically opted-in by Google into a new tracking and advertising mechanism. Arguably, the right thing to do is an automatic *privacy update* that maintains the status quo. Explaining this clearly would avoid the possible and justified loss of trust involved with making “security update” an unwarrantably elastic term.

Agree. Clarity of language matters.

But WP should definitely do it.

+1. This is a privacy concern (that I’m glad we’re discussing), not a WordPress security bug.

Support the change, however, the patch suggested could overwrite existing `Permissions-Policy` headers, when this should instead be appended if one already exists

Won’t this hurt e-commerce sites?

Can someone even explain, providing concrete facts not just assumptions, as to how having a browser be part of a group of hundreds of thousands of similar other browsers for a week is a security threat?

I say leave this up to users. If someone feels threatened by this – stop using Chrome.

FLoC is a privacy concern. So it should be treated as a means to leak private data, which I don’t think WordPress should be a vehicle to. WordPress has been there for the users, not the big tech. +1

Agree with doing this absolutely.

It’s privacy, not security, though.

Should be simpler than adding a filter to reverse out too, but I will support making FLoC off by default in WordPress in very near future, even if we cannot backport it.

+1 for prominent notices on update explaining the change and why it’s happening, too. I don’t think many people would opt in to this, given the choice.

All we are doing, is giving them that choice.

Hi,
As webmaster of two associative WP sites, in which I try to be the most respectful for the privacy of my visitors, it’s a big « +1 » for me.

So, I vote yes.

If WordPress were to choose to move forward with this proposal, back-porting to a current minor release as a maintenance thing happens all the time (They’re usually security & bug fixes, but sometimes slight changes in behaviour), there’s no need to treat this as a “security issue” and this proposal misses the point of WordPress minor releases.

But speaking personally; This sounds like an individual privacy concern, and not something that WordPress – as a neutral publishing platform that can be used to share whatever where ever you want, should take a stance on.
WordPress doesn’t block other forms of browser tracking, why should this be any different? WordPress allows you to use an unscrupulous ad provider on your site, but importantly it doesn’t prevent you from using it either.

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 & people visiting WordPress sites would expect that either.

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 favourites. If this proposal made enough of a dent in the FLoc usability, advertisers would simply have to move onto a different protocol that wasn’t blocked (Or work out a way to ignore WordPress saying no).

I’ll echo the concerns raised by Dion here about blurring the lines of what is security and what isn’t, as well as this then setting a precedence that will require following up on any changes in headers for individual browsers and where does one draw the line on what headers and what browsers to allow/block? Given that this isn’t a standards thing, but rather a single browser (although a popular one), these are things that need discussing and properly outlining and having an actionable plan for before anything else I feel.

I’ll also add that although backporting can be done, this is primarily for security, there’s a difference between adding it to an upcoming minor release, and backporting it (which would generally include previous versions of WordPress as well). The official stance is still that only the latest major version of WordPress is actively supported, so we should avoid adding more weight on maintaining older versions when possible.

A thought that came to me; If this is tracking by default in an upcoming browser version, would we not see an opt-in prompt in the browser it self, to comply with EU regulations, and would such a prompt not then cover all bases for everyone? I’ve obviously not looked into how it’s being implemented, so I am asking out of interest here.

This sounds like an individual privacy concern, and not something that WordPress – as a neutral publishing platform that can be used to share whatever where ever you want, should take a stance on.

Same thoughts. I don’t agree with what FLoC promises, but this is more at an individual level and a privacy matter.

Treating it as a security issue might also make it difficult for those who actually want this or are okay with this. Security fixes prevent threats/vulnerabilities. Would we then allow people to opt-in to threats/vulnerabilities? E.g., for those who want it enabled.

The original proposal didn’t mention a FLoC opt-in option, but it was brought up during discussion, and I’d like to briefly address it.

If WordPress treats FLoC as a security concern, how would it justify letting users opt in? Security fixes are unilateral by definition, users don’t get to opt back in to the threat that was eliminated. WordPress even backports those fixes to a number of legacy versions. The only way to opt back in to a previously eliminated security risk after a security update would be to manually re-install an insecure version. The fact there isn’t any option to do that is by design.

Making WordPress opt out of privacy-invasive third-party technology by default is one decision.
Offering an opt-in option for the same type of technology is an entirely different one – and arguably the bigger political statement at that.

Good on you all. That the literal browser makers are circumventing privacy and it’s falling to the CMS creators to overcome this. Bravo WordPress, Bravo!

Apparently despite this being on make.wordpress.org does not mean it represents a thing done, or that it will be done.

Also, not sure if I’ve misread the header spec, but shouldn’t the notation be

`interest-cohort: none`, and it patch the header (something I didn’t think needed to be done, but now I get it, it’s not on or off, it’s a series of flags, for some reason set using headers).

The internet never fails to disappoint.

@lewiscowles
Just to clarify, make.wordpress.org is used to discuss proposals.
The trajectory for this is:

This will be discussed during Dev Chat on Wednesday, 21 April 2021 (on Slack). Anyone is welcome to join. You need a Slack account.
If there is a consensus (/broad support) among the Core devs, a core ticket will be assigned a “blessed task” status – and we will be able to include it in a minor, rather than a major release.

We’ll discuss more implementation details in the ticket (this will be on core.trac.wordpress.org).

Some of the awesome Core devs who have already offered to help / others who want to will then create a patch.

The purpose of this post is mainly to discuss whether:

We should do this in the next minor version of WordPress (as new “”features” are normally only included in major versions);
This should be back-ported to older versions of WordPress.

So, it is very important for EVERYONE, not just Core devs (although I am glad to see so many of them around!), to share your thoughts here.

+1 for me, with a couple caveats :

the header needs to be appended to existing Permission-Policy header if it exists, as noted above, there are others that can be and are used already.
It should be the default to block FLoC, but an admin should have a way to turn it back on through the UI (because many sites rely on third party tracking for their revenue, and, want it or not, it’s a reality that can’t be escaped.

And last, but not least, we all rely on the wishful thinking that this header would be honored. Famously, the ‘Do Not Track’ sent by browsers is already mostly ignored by the advertisement industry, I’m not sure that the Permission-Policy header would not similarly be discarded, when the method extends to other browsers (and it probably will, expect a W3C standard proposal pushed by Google and it’s cohorts sooner or later) and i don’t expect Google to build an ironclad code in the tracking method to make certain that this header would be honored in all circumstances (actually I expect them to make sure it can be bypassed at some point, yes I’m distrustful like that ;))

Hello,
Thank you for the proposal. Let’s make sure this item is discussed during the next Devchat (on April 21, 2021 at 20:00 UTC, in the core Slack channel).

By the way, if there is an agreement on this proposal, we don’t need to flag it as a security issue to ship it in a minor version.

Not a core dev, but a long-time WordPress user (since 2004); I strongly support building this into WordPress by default, with an option to allow admins to opt into FLoC.

Strongly want this as a simple user, not as a developer!

This could make a huge positive impact on the world! Please incorporate this into core!

By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.

Yes! Do asap!

Bonjour à tous,
En tant que webmaster et webdesigner, j’essaie d’être le plus respectueux possible concernant de la vie privée, Je suis entièrement d’accord avec la démarche de bloquer par défaut.

Another suggestion to combat FLoC.

Remove Chrome from https://browsehappy.com/ which is ‘brought to you by WordPress’ (the link points to wordpress.org, so it’s a community site) since we do not want to advise people to use privacy invasive browsers. Or do we?

I’m not a core developer, but I still would like to add my 2 cents here.

A security issue would be if there was a risk of the website (or a visitor’s browser) getting compromised. That’s not the case here. Regardless of whether one likes this technology or not, when stuff follow the suggested standard and won’t reveal any additional data than the standard suggests, then it’s not a “security issue”.
In maintenance updates, we usually only include fixes, but don’t add features or change functionality. But that’s not a 100% rule. The most prominent case of the opposite was when we in reality got new functionality for GDPR support via maintenance updates, since “WP 5.0” was earmarked for the “Block revolution”. So the really important rule here is that a maintenance update should never ship any new files. (Thus initial implementation of GDPR compliance didn’t live in its own files.)
Now that I’ve learnt about it, thanks to your post, I personally, don’t like the idea of FLoC.
We usually say that WordPress in its design should aim for “decisions” rather than “options”. To me, this means that it could be OK for a future WordPress version to decide that by default WordPress is going block FLoC. But we should not backport that kind of decision to previous WordPress versions.
Until recently, we’ve been very cautious about adding new strings in maintenance/security updates (but still, it has been happening regularly). Although spurious new strings may be a bit inconvenient, they’re less of a concern now, after we lowered the threshold in percentage of translated strings for localized WordPress packages.
So: if we’d backport anything for this to WordPress 5.7 or earlier, it would need to be something that would not change the default behavior of WordPress, i.e. it could be a new option under Settings→Generalm but it still should not enable this “protection” by default, but be there as an active choice for the web admin.

Alternative approach: we could inform about the plugin that is available via a post in /news and an article (or two) on wptavern, so that more people would learn about this and take action. And still aim for a “decisions, not options” solution in version 5.8.

If we want users to take the words “security concern” seriously, we shouldn’t mislabel privacy preferences as a security issue.

And the irony of WordPress fighting for privacy rights while simultaneously making it easier for developers to enable server side tracking…rich.

As someone who works in the advertising and marketing space, I might be biased. But my opinion is that this planned move will backfire. Instead of making people “safer”, it will accelerate server side tracking expose users to even more of the supposed “risks” associated with tracking.

I understand FLoC as a privacy issue but not a security issue.

Meanwhile, Google have no plans to activate FLoC in Europe, due to GDPR policies (https://techcrunch.com/2021/03/24/google-isnt-testing-flocs-in-europe-yet/) so, as many other privacy options, in case of incorporate the FLoC block in WordPress I think that should be as an option for admins.

I have a problem with treating a values-based feature as a security issue just to hasten its arrival. Nowhere in this proposal or the comments have I read a description of how FLoC introduces an actual or potential security risk for site owners or visitors. Changing behavior as part of a security patch violates the hard-won trust of WP admins that security updates can be installed without side effects.

I’m in favor of adding a filter that allows admins and developers to opt-out if they choose. This could be added in a minor release, and even back-ported. It would benefit the community to have a standardized way to address this ASAP.

But activating the header by default would be an opinionated change in behavior, and I do NOT think WordPress should try to sneak such things through without allowing for a thorough conversation among all stakeholders (including the tens of thousands of business WP sites that serve targeted ads or use them to reach their customers).

The key differentiator between FLoC and 3rd party cookies, as I see it, is that 3rd party cookies are/were only ever present because the site owner added (opted into) a 3rd party request. FLoC flips the pattern and requires a site owner to opt-out. So, there’s a fair argument that defaulting to the opt-out header just preserves existing behavior. But that argument should be made clearly and consensus reached if possible. The right place for that is a major release, with a UI setting to re-enable FLoC if the site owner chooses. Given that FLoC is still in testing and only active for a small fraction of Chrome installations, and there’s no timetable for its wider activation, I don’t see how there’s a compelling need to get this in ahead of the 5.8 release.

Yes. We should *absolutely* consider the tens of thousands of business sites that make use of targeted ads, or serve them to customers.
We should also consider the millions of sites that don’t.

Honest question for everyone participating in this conversation. Well, two:

When did you find out about FLoC?

I know for a significant number of people here, it was yesterday or today.

If you went and asked 20 of your family / friends / neighbours now, how many of them would know what FLoC is?

I am going to try very hard to stick to my resolution to give this conversation space to grow, so if I do not respond to comments, trust me, it is not because I don’t want to. Lol. I would love to engage on these matters, because there are some valid questions being asked here – and some great suggestions.

In the interest of moving this along, I would ask people to consider:
Who is more likely to be able to make an informed decision about FLoC?
A person who is running forum software for a support group for sexual abuse survivors (or LGBT youth) in their spare time who has likely never heard about FLoC, nevermind how they can opt out?
Someone who is running a business site with an e-commerce plugin, a SEO plugin and a plugin to connect them to Google Analytics?
Surely those plugins are in a good position to help educate those of their users who need education / assistance to opt in?

Also, Google recently had to settle with the FTC for COPPA violations. They are currently subject to a class action lawsuit for those alleged violations.
Since FLoC will expect websites to opt out, not opt in, how will this prevent the profiling of children?
Will FLoC respect do-not-crawl and do-not-index directives for private sites? Or will it be de facto indexing sites (even those that require login) by people’s browsing histories?

Google (or at least some of the people at it) know that it is easier to ask for forgiveness than permission.
Building awareness through education is a slow and labour-intensive process – the Law is even slower and legislative development even slower than that.
They find their old technologies inconveniently regulated, so they create new ones that do the same thing before people know it exists or what to do with it.
The belief that privacy is an “individual” thing is exactly what gives them so much bargaining power in the market.
This proposal simply says “No. You will ask for permission – and if you won’t, the answer will be a hard no.”

I agree with what you are saying here 100%, of course it is more difficult for a site with a vulnerable community to handle this and I think it is easy to expect people already interested in monetizing their website to look into this and do what they have to in order to turn it on. That said, I also think there are plenty of businesses that are not keeping close track of this sort of thing either and would likely find some benefit from FLoC without realizing it. I agree that in general whatever comes of the FLoC proposal it will require a more significant effort to educate the general public.

That said… I’m not sure turning this off by default is something that is right to do at the level of WordPress Core. At least for now. I think making it easy to filter is good and should be done, but as you note at top this could have a huge impact. This is both for the users for whom it is blocked and for the ecosystem of the web and the potential for different monetization approaches. I think that all the points here against FLoC should be brought up as part of the general standards discussions that are happening, and I hope that they will better be taken into account in the final product that comes out of the web standards discussions.

WordPress Core does not block logging in with Google as a feature or block third party cookies or browser plugins that might observe browsing behavior to whatever extent that could be possible. And the same argument you have here could easily be made about Log In With Google. Most people are going to install something like that without thinking through the implications or being aware of the tradeoffs. I’m not sure it is Core’s role to step in and put a warning before a user installs something that calls back to Google or otherwise tracks users demographically either? What about a Facebook pixel or button? Even though it’s only recently that sites that serve vulnerable populations have been pushed to stop using things that cause their users to be tracked. I can see the argument for say, putting a warning alert up when the user installs Analytics, or activates AMP, or Google Ads, or any advertising related plugin. But I’m not sure it’s the right way to go.

And I worry about what this promises to users if it is defaulted to off. If FLoC becomes less effective and some other standard rises up do more changes need to be made? Does this become a continual back and forth? What about browser extensions that use the FLoC approach without listening to the FLoC opt-out signal? The current standard is not even completed and whatever the end product becomes and what these various signals mean is not set in stone. I just worry that such an early move discourages any attempt to make for a more private but still sustainable web.

Personally, I’m pretty split about FLoC. I think the current proposal needs work, but as someone who has worked with publishers trying to make money for a while now, I’m uncertain if it represents a potentially viable and safe future pathway. I personally intend to experiment with it because I think there may be some potential future to something *like* it, even if I dislike the current iteration. To the extent this decision is or is not appropriate as a WordPress Core Default, I can see great arguments on both sides here, but also I think it is reasonable to wait and see the finalized version of the proposal before baking this in. Perhaps, though I will admit that it is highly unlikely, the final version of FLoC–if it ships as a production feature of Chrome at all–will address the concerns at hand. Personally speaking, I would like to see the end product before I make the call. The current proposal represents only a fraction of the overall Chrome users and sadly the potential harm it might create is already realized by third party cookies and users of Chrome until such a point where browser features like third party cookies are turned off in Chrome.

I think if we get to the point where FLoC is set to become a Chrome production-level feature and these concerns remain unaddressed, at that time it might be reasonable to make the call to default FLoC to off. Even if this is the right place to intervene, I’m not sure it is the right time.

These are good questions. Here’s another one:

Let’s say that WordPress’s core stakeholder and “target market” — very generalized — is the independent publisher: the blogger, journalist, ecommerce shop, group leader, activist, product reviewer, or business that wants to own & manage their own presence on the web, instead of depending on some large corporation’s walled garden and ToS. We can (and should) be concerned about helping & protecting end-users, but ultimately the effects of a decision on independent publishers ought to weigh most heavily in our consideration, in my view.

So what happens if ~40% of the internet goes dark to FLoC? How does that impact independent publishers?

Suppose that makes it significantly harder for FLoC to build its aggregated groupings, to the point where it’s much less useful. The barrier to entry for effective targeted advertising goes way up: you need first-party data, you need server-side processing. To everyone who cares about online privacy, this is a win; drive-by tracking is dying out.

But does this lead to a drop in revenue for ad-supported publishers? Does it raise ad prices for businesses trying to reach their markets?

And then what? Does that stimulate development of new, decentralized ad markets, that give site owners more control and build less invasive visitor profiles?

Or does it drive more publishers into the walled gardens? Does it force more publishers to say “Ad revenue doesn’t pay the bills anymore,” and throw up paywalls, shrinking the amount of freely-available knowledge and creativity on the web? How many of those can make their paywalls convert well enough to survive independently, in the face of subscription fatigue?

The internet may be more private at that point, but if it’s also less useful (unless you’re affluent enough to casually pay for a bunch of little subscriptions), whom did we benefit?

I don’t know the answers; I doubt anyone really does — but we still need to ask the questions. This is a Hard Problem. It’s also one that WordPress, as an open-source tool for independent publishers, is uniquely well-positioned to consider soberly without conflicts of interest from economics or prior ideological stakes.

This proposal simply says “No. You will ask for permission – and if you won’t, the answer will be a hard no.”

I’m deeply skeptical that any CMS should be making that decision for its users (meaning site owners & admins).

FWIW, I’ve known about FLoC and the Privacy Sandbox stuff for a number of months, casually watching them both as a privacy-interested user and a technical marketer doing advertising work. I don’t like FLoC much from either perspective… lots of problems, as you touched on.

But if WordPress is going to block FLoC by default for qualitative reasons, there needs to be a clear statement of values explaining why we think this is unacceptable as a default, and where the line is drawn. Otherwise, we’re just picking winners and losers based on arbitrary opinions, and down that road lies a lot of acrimony that I doubt anyone wants.

I agree with much of what Aram and @andronocean have said. I am not actively involved in the WordPress community, so won’t comment on many of the policy/approach questions that are being raised, but one thing that andronocean wrote that rings true for me is who the core stakeholder is for WordPress, which I also believe is independent publishers.

The company I work for is the largest advertising representative of independent publishers’. We run the ads for thousands of publishers, 90%+ of which run on WordPress. These publishers are creative individuals who are able to make a living doing what they love and given a platform for expression that’s supported by ads. They’re able to bring their amazing content to hundreds of millions of people around the world that’s not locked behind a paywall. For many of our publishers advertising is their largest source of income and supports their family and/or their business.

When third-party cookies are turned off in Chrome, if they are not replaced by equivalent technologies (like FLoC and the other parts of Google’s Privacy Sandbox), advertising will suffer on the open web, and independent publishers will be harmed. The money that they lose will flow to the “walled gardens” like Google (google.com, Youtube, etc.), Facebook and others.

It’s also likely important for FLoC to ultimately have data from many sites, not just from sites that opt-in because they are ad-supported, and certainly would be more optimal for the purposes of testing that Google is doing right now. If only publishers that make money from ads opt-in, that limits the pool of sites that FLoC can “learn” from. But it would be better to also have the thousands/millions of WordPress sites that are run by advertisers be part of the FLoC calculations.

FLoC already has a fairly good (if not fully transparent) rule that it only calculates cohorts from sites that run “ad-related resources” – which covers most publishers that make money via advertising and also covers sites that want to advertise. By default this means that many sites that have sensitive information already would be “opted out”, and perhaps Google will add more restrictions in the future – and a WordPress decision can be made before the feature is live in Chrome.

There are real and valid implications of FLoC from a privacy perspective. But to Aram’s point, right now FLoC is just a proposal that is being tested and isn’t being used for any targeting. As the proposal is hammered out and improved, and transparency is increased, many of the negative implications may be handled. And if not, we all have more information to make better decisions as Google moves towards rolling this feature out.

I and others at my company have been very active in the W3C over the last year, and working with Google and others to try to make these proposals better for users and also for businesses, and within the W3C, the user is the most important constituent. But from reading the WordPress mission statement, it reads to me that the most important constituent is the creator. And it’s unequivocal that without replacement technologies for 3PC, like FLoC, independent content creators that earn their living from advertising, will be harmed.

I can get behind and support anything that educates the general public (technical or not) about personal privacy while browsing the web. To say that this is a “personal privacy choice” indicates an understanding of privacy, and I would wager that 99 out of 100 new persons I meet cannot fully understand how tragically their own personal privacy is compromised. Even for a developer it is hard to follow that rabbit hole to the bitter end.

It should be a personal choice, and as the global WordPress community, we can help educate our larger communities about privacy choices, how to make them, and what they mean.

How can we use Chrome’s decision to roll out FLoC in this way to educate our personal network?

How can we, through WordPress, educate content creators, developers, and engineers on FLoC an other privacy matters?

(⌒▽⌒)♡ These are rhetorical questions, and I am asking myself first. (￣人￣)

Another option to not support or let your website be part of FLoC calculation is to simply not use any form of google (or else) analytics, ads and consort.

According to EFF, FLoC only will „work“ if your website accesses the FLoC API or if Chrome detects that it serves ads. You could in these cases additionally opt out of this calculation by sending the following HTTP response header:
Permissions-Policy: interest-cohort=()

I personally run a _successful_ online business without google analytics, without Facebook pixels, without submitting data to or getting from any analytics service available.

It is possible, and the biggest reason most web admins use the „free“ analytics services IMO is because they believe it brings customers. But does it really? Or does it give data for free to data brokers?

„Free“ always means there’s a hidden gain, so it’s no surprise things like FLoC are invented and pushed. „They“ need to make money somehow, too.

I find it great that WordPress wants to spread awareness about these practices, and support any form of action taken to avoid big data corps using our websites and our browsing behavior to (do whatever they do with it).

However let’s not forget that this is all only possible because _we use_ their services. So I think perhaps spreading the information about it and letting users know what and how they can avoid it, is enough. It doesn’t need a code change in core. This will just „hide“ the fact that it’s happening, because site admins wouldn’t need to „worry“ about this aspect (if automatically handled by core)

Just my opinion as both a WordPress user and someone who’s making a living by developing with WordPress

To preface all this, I’m anti-FLoC. I killed it in htaccess for everything on my domains since not everything is WP (sacrilege, I know).

I agree about not calling it a security update. We have precedent for it as a privacy related update. Which I get is splitting a hair, but it’s not security in the classic sense of “Without this, WordPress is less secure.”

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

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 IMO.

I will note, also as a webhostie person, we’ve already breached the trust with breaking minors a couple times, for good reasons all of them (breaking some shortcodes was a fun one).

The ultimate question here is “Is this a good enough reason?”

Honestly I don’t know.

I personally, someone who is a minority and already has faced a number of crazy things, feels that for me it’s massively important. But do I get to make that decision for everyone? Who’s responsibility is it to educate and inform and protect everyone? Is it ours at WP? Is it browsers?

It’s kind of the fundamental flaw in the web for everyone! Who’s job is this!?

So. This is related. Cookies. WordPress core doesn’t disable cookie tracking at all. That is a choice the site-runner has to make. This is pretty much the same thing. And as much as I personally find this distasteful, it strikes me that this is outside of WP’s auspice in so far as a CMS has any. I would be interested to know what other CMS’ are doing (quick search didn’t drum up anything).

While I’ve already implemented it via .htaccess on my sites, those headers have changed before. Also there’s this concern I have that Google will just move the goal posts on us again and change it in a new way.

I despise that my end thought here is “This is not our responsibility as part of core.”

This ^ all of this. It should be available in core in a future release; it should not be force-patched to old installations; it should be available to old WP versions via plugin; it should be optional. Mostly, it should be available.

Yeah I think this makes the most sense to me. I think we’d probably want to make it a Permissions-Policy header filter instead of one specific to FLoC.

I hope this goes through – great to take a stand against privacy intrusions. Google takes too many positions on how websites should be built and rarely listen to the builders. It falls just a bit short of personally identifiable information, but there is some and that does in my opinion fall both privacy and security since most breaches intend to steal just that.

Create the built-in patch for the next version of WordPress with a selection in settings to enable (or not) as the developers see fit.

In the meantime, count on the plugin(s) to amend previous versions as desired.

I imagine over time; many plugins, patches, and tips to add new headers, etc. may result from some of the discussions and news around this subject.

A campaign within WordPress to make people aware of the subject might also be a good idea. But WordPress doesn’t need to get in the middle of the arguments for or against.

I have no interest in the subject myself…

What the search engines see as my habits and interests are probably far from reality. Anyone purchasing data about my activities should realize that any interests that might be perceived or inferred from my search subjects may result from my curiosity and possibly my desire to manipulate results.

Let the chips fall where they may.

Content is always King!

Hey there, Chrome DevRel team here, I wanted to add some context and resources for this discussion.

FLoC is currently deployed as an origin trial in Chrome. This means it’s running as an experiment that affects a limited number of users over a limited amount of time.

Specifically, during the origin trial sites are *only* opted-in to the FLoC calculation if they use the FLoC API themselves or if Chrome detects they are loading ad-related resources.

That means that if a site *does not* load any ad-related resources and *does not* use the FLoC API, then it *is not* included in the FLoC calculation.

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. 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.

Unless a WordPress default install includes advertising, the origin trial will only affect installs that have added ads-related resources. That makes me feel that a plugin approach would be more appropriate for sites that want to add both advertising and opt-out of FLoC at the same time.

Likewise, if you are interested in how FLoC can provide a migration path off using third-party cookies or other forms of individual cross-site tracking, then you’re very welcome to actively participate in the origin trial as well. The aim is to prove that this path is achievable through large user groups that do not expose sensitive or personal information. If you explore the repo, you can see a number of issues that get deep into the detail of how to achieve this and we’re more than happy to expand on the details there.

Resources for further reading and contributions:

Okay, I’ll bite Let’s talk.

I understand that this is currently in a trial phase – and that it currently affects a limited number of users over a limited amount of time.
But since we’re engaging in straight-talk, Google’s privacy settings are opaque to put it politely.
Let’s say that I want to watch YouTube without being tracked, I can’t just pause my search and watch histories and opt out of behavioural ads on YouTube (that’s already three settings I needed to know about).
I also have to know about “Do Not Track” in the Chrome browser (although very few sites actually change their behaviour based on that signal), the opt-out of interest-based ads under Google under my phone settings (which will disappear the moment that I clear my cache), as well as needing to know that I can’t back up my WhatsApp messages to Google Drive because then the messages are not encrypted.
That is OTHER than needing to know that, even if I browse Chrome in incognito mode, if I were to say, visit a NSFW site, chances are I’m going to start seeing adult toy unboxing recommendations on YT (and then you call the advertising contextual, rather than the indirect behavioural advertising it actually is), unless I know where to turn off YET ANOTHER setting buried in yet another place in my phone settings.

You state very precisely that the data is “not taken into account” for the FLoC calculation – but it is data that you are not entitled to be collecting and storing in the first place – particularly when it comes to sensitive information like medical information and information about sexual preferences.
Opting out of behavioural advertising isn’t quite the same as not having the data stored and collected in the first place, right? The data is still there, just waiting for the moment someone actively stops saying “No”, isn’t it?
Fine, you want the calculation to be federated, but you do need a central controlling authority to make sure that the cohorts do not correlate too closely to protected classes, so you’re sending that data somewhere, right?
I’d also like to know, if this is going to be opt-out, how are you going to be ensuring that you comply with COPPA and do not collect information on children?
How will this prevent large organizations with access to PII to simply recombine what they know about users to finger-print them, now with vastly more information about their personal preferences and sensitive information?
And while we are on that subject – can you honestly tell me that large corporations won’t benefit a whole lot more from participating in FLoC than small websites (where you’ll be getting a lot of the behavioural information from) will?

In terms of following a plugin approach – users actually have to know that FLoC exists and that they need to install a plugin – and some hosts do not actually allow plugins to be installed, so unless the host is going to install it as an MU plugin, the site owner won’t get a meaningful choice.

In terms of participating in the trial, contributing to the repo, etc: Those are pretty high barriers to entry. You do this as your job. Awesome. Really. But you cannot expect all of the stakeholders who are affected by this (including the general public without any development knowledge) to have the knowledge and the resources (including time) to participate in building your product for free, or to jet around the world to participate in standard-setting. If you want to experiment on people, you should get their informed consent. As simple as that.

I would like to see this proposal reworked with the following:

A plain language explanation of the difference(s) between disabling FLoC on the site level (i.e. as the content provider) vs. on the browser level (i.e. as the content consumer). Some potential items to answer are: what are the benefits of disabling as the provider rather than leaving control to the consumer, and what are some hypothetical examples of the effects of disabling FLoC across all WordPress sites at once (i.e. on an individual user’s privacy and where it might push ad technology).
Removing references to this as a “security” item because it is not, and being specific that the point at hand is whether to commit this in a minor release and backport it and to how many releases.
Justification for triggering the amount of work involved in backporting and serving that number of updates, especially around concerns regarding user trust in minor releases/autoupdates and update fatigue.
Opening a Trac ticket for reference and discussion regarding its place in core and implementation. Without that it is premature to discuss the inclusion process, I do not believe there is even consensus around this item to begin with.

I believe you have since edited the post without indication as to the edit – in the future, you also need to indicate edits with a date/time of edit. Consensus regarding implementation should happen on Trac as a more permanent resource, not a Make/Core post. Deciding on a release to include something that isn’t agreed upon yet is backward.

Please do not unpin my comment again, I am requesting kindly but it is a request from a lead.

I have not made any edits without indicating exactly what they were
I believe you may be confusing my edits with the edit made by Tom, where he corrected a typo of “;” to “,” in relation to his code snippet.
The information is contained in a comment exchange above, for your reference.

It needs a timestamp, e.g. to note that your edit including “consensus building first – and that is done here” (which remains incorrect) happened at 07:08 UTC today, after my comment regarding consensus at 00:40 UTC. This gives readers full and appropriate context.

(Comment edited to fix threading and change i.e. to e.g., since comments do not have revision history)

What does Floc have to do with racism?

I highly recommend reading:

The EFF’s commentary on FLoC;
A blog post by the FTC regarding the possibility of discrimination (not just racism, various other forms too) made possible by big data approaches.

The TL;DR version is that:

People with low credit scores (who are often disproportionately non-white, although, of course, there are many poor white people too), for example can be targeted disproportionately with predatory lending ads;
People can be excluded from being shown houses in lower-crime neighborhoods / good school districts, etc., based on browsing habits that correlate with their culture (again, the correlation isn’t perfect, but it is quite high);
People can be excluded from job ads, based on their browsing habits and personal choices, including their religious and political views.

I will read later when I have time, however, based on the TL;DR, none of this is racist or discriminatory. It’s marketing based on assumptions and generalisations, like all marketing since the dawn of time. There is no point in marketing a $2 000 000 house to someone who most likely can’t afford it.

I like the pro-privacy efforts and I respect the ambition, but I think the social justice stuff is a bit over the top. A lot of credibility is sadly lost when involving politics.

based on assumptions and generalisations

Historical instances of people being grouped “based on assumptions and generalizations” are numerous and have never been good in the end. Absolutely none of the concerns raised thus far with regards to this have been unfounded.

There is no point in marketing a $2 000 000 house to someone who most likely can’t afford it.

Because this whole system is based on assumptions gleamed from browsing habits. It has no way of knowing the viewer can’t afford a $2m house, it simply assumes they can’t, using time-honored discriminatory tactics.

Historical instances of target audience marketing ending up bad? Where? Source?

I say let marketers decide their own target audience. If it works 100 or only 40% of the time is irrelevant.

If WordPress will block Floc by default, then I don’t really mind. I just think the arguments on why to do it is based on the current zeitgeist ideas of social justice, which is not a neutral point of view. It is actually pretty ridiculous that some groups remain eternal victims, and now an internet ad will threaten their way of life. Gimme a break. I’m being actively excluded from tons of potential jobs because some diversity officer decided there are enough whiteys, and people are whining about an ad which you can block by using uBlock origin.

Imo, remove the text about LBTQ+ stuff, it is absolutely ridiculous to even mention it when talking about Floc.

Historical instances of target audience marketing ending up bad? Where? Source?

I said “historical instances of people being grouped based on assumptions and generalizations.”

If you’d like a source on that, please open a history book or your search engine of choice.

It is dishonest to bring up Godwins Law like you just did. We are talking about advertising and privacy here. Do you think it is wrong to wear uniforms because bad people did that?

It is dishonest to bring up Godwins Law like you just did.

I didn’t, but you just did, so .

Do you think it is wrong to wear uniforms because bad people did that?

Nope, and that’s not even remotely related to what I’m saying.

See what Jaroslav wrote, he explained it better.

I did and have already replied to it, but thanks.

Historical instances of people being grouped “based on assumptions and generalizations” are numerous and have never been good in the end.

Respectfully, this is also a generalized claim that you infer from (I assume) a few select sociopolitical instances, while ignoring other.

There are many instances of people being grouped on assumptions and generalizations that have been good in the end. For example feminism builds on top of a generalized view of male and female position within society and have led to a net positive societal changes.

The issue here is that you probably should not make parallels between things that are different from each other.

Target groups in advertising assembled based on observed behavior (!) are something different than groups of people being treated differently by a state regime.

I don’t think you can make parallels between the two just because the language is similar.

That’s a very fair and very well-made point, thank you.

I will add a caveat that my main concern is when forms of negative grouping have lead to negative action on those groups.

That has happened, and there is ample evidence of it.

While FLoC is “new waters” with regards to what has happened in the past, time will ultimately tell what may come of the data collected and how it’s used.

It may be innocent enough now, but it also wouldn’t be the first time an innocent effort has ultimately been used to discriminate.

I believe the HUD and other departments / agencies have already dealt with discriminatory practices in terms of directed advertising for housing. If I am not mistaken, Facebook was charged with racial discrimination for this very reason in 2019. [It seems that they also had to settle with five civil rights organizations.]

Globally, I believe there may already be criminal and / or civil cases with regards to using directed advertising for predatory lending.

This is not a new problem that we are “borrowing” from the future.
FLoC may very well make websites unknowingly [and unwillingly] complicit to this sort of discrimination, make it easier for those who already discriminate to do so more easily, while simultaneously making it harder to prove the discrimination is happening.

I’m not the first to say this but I think there are a couple of discussion points here:

Should we enable FLoC for sites by default?

Our (Yoast’s) point of view is simple: we don’t enable tracking by default, so we shouldn’t enable FLoC by default. So: yes, we should indeed disable it and provide a filter for developers to enable it.

Google has made this opt-out instead of opt-in for websites, which is in my opinion the wrong way round. We should reverse their decision and make it an opt-in choice for sites running WordPress instead of an opt-out choice. People can then install a plugin to enable it if they want to, just like they do with for instance Google Analytics or Jetpack tracking.

Should we treat it as a security concern?

It’s not a security concern, so we shouldn’t treat it as such. Whether we should backport it doesn’t have to rely on whether it’s a security concern, we could also decide to backport this because we as a community feel that this should be opt-in instead of opt-out. I myself don’t feel strongly about this, I think people should just update anyway

I spent yesterday jumping on Twitter threads pointing out this was a contributor proposal, and not by “WordPress”.

@photomatt has finally Tweeted something
https://twitter.com/photomatt/status/1384197185219170305

I think it is also important to read this clarification by one of the Google engineers
https://twitter.com/Log3overLog2/status/1384337637763387394

Now thinking about users… i.e. the readers of a blog. They deserve choice.

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

That might seem strange, but there are users who say yes to 99% of tracking cookies. I do it on 1 of my devices because I want to test and see what advertising people use.
Plus FLoC isn’t the way Google will “follow” you around the web because you left something in a shopping cart with remarketing.

Is it WordPress’s job to prevent someone from seeing more relevant advertising for products they are more likely to buy, events they might want to actually attend etc.?

I think a better response might be more a grass roots “how to opt-out” of FLoC campaign, drive users awareness and how they can block FLoC everywhere.

This is a valid concern about user choice. I think there’s only one “correct” solution:

Google Chrome needs to make FLoC “opt-in” at a browser level.

However, this is not going to happen. So we are left with the decision to impact consumer choice in two ways:

1. Do we allow FLoC to track users when they visit a website without their explicit consent? If so, we violate the choice of users who don’t want to be tracked.

2. Do we disallow FLoC, and (as you mentioned above), violate their choice to see targeted ads?

In the absence of Google explicitly “opting in” users at a browser level, I feel that (1) is the choice more respectful of visitors to our website.

Absolutely disagree with the current proposal.

It’s not a security concern and shouldn’t be treated as such. I also find – and not just this – response to be very reactionary.

We currently don’t now how FLoC will exactly work (in final form) and what changes to API (and not just API) will be made. It’s currently in early “trial” phase and should be treated as such.

As far as we know, if FLoC will truly go ahead in the future, there will be in Chrome (so far the only browser not disabling it) an easy ON/OFF switch.

These types of decisions should be always on consumers and hosts, not on CMS and being disabled “behind the back” because “well, devs and admins that want it can find a solution”.

It’s also very important to understand how big of an impact it can have on publishers and websites relying on monetization. Suddenly turning it off behind the back for millions of websites is dangerous.

I am publisher myself and I rely on AdSense heavily. I don’t want WordPress to push something disabling it for my “better good”.

I use WordPress for technical reasons, not for being my daddy.

Absolutely agree.
Any fingerprinting technology should be considered a security issue. I understand that there are people who want to enable this manually on their site. However, by default, you need to block such things so that most sites on the Internet do not violate the rights of most users.
P.S. Sorry for my English, but I cannot be silent.

There are contributors and users from all around the world
You are very welcome here!
You can also join your local Slack community to connect with other people from your area and in your own language: https://make.wordpress.org/polyglots/handbook/translating/teams/local-slacks/

WordPress currently releases security updates for versions 3.7 and upwards (21 versions at the time of writing). The security team have discussed this as a group and reached a consensus.

The WordPress project’s current support policy is that only the most recent major version should be considered supported. At the time of this post, this means that 5.7 is the only maintained branch. However, security fixes are backported as a courtesy in an effort to promote a more secure web (currently) all the way back to the 3.7 branch.

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.

Thank you for the feedback. Appreciate it.
I do have a question, if you don’t mind?
Not trying to put anyone on the spot here. This is a question that a lot of people feel very passionate about, regardless of their opinion and it seems like a good thing to have open discussion about.
How would the Security team treat the addition of an unauthorized cookie from an unrelated third party source?
I do believe that if a plugin added tracking (whether via pixel, cookie, or another method), that would result in removal from the repository, @ipstenu?

If the plugin was a plugin to facilitate tracking via a pixel or cookie etc, and disclosed it’s purpose as such, it would be permitted.

If a plugin added it in to track people without consent, and without disclosure for opt/in, then it would be removed.

However, this isn’t a matter of WordPress adding a tracker. You’re talking about WordPress blocking a 3rd party. To extend your analogy, if WordPress Core actively blocked a specific external Pixel tracker, that’s a bit of an over-reach. And I agree, it’s not security. Privacy, yes, but not Security.

Thanks. My question did refer to plugins tracking without specific opt-in consent / disclosure, but reading it again, I realize that the meaning did not come out as clearly as it should

Yeah, I get and respect your opinion on the security vs. privacy distinction – and as stated my main goals are inclusion in a minor version and / or back-porting anyway – which classification as an “enhancement” would likely preclude.

That having been said, I am a firm believer in substance over form – classifying something by what it is / does and not by what it is called.
I don’t believe we should de-facto “allow” the same functionality (tracking without opt-in consent) just because a different mechanism was employed and something was given a different name. If it walks like a cookie and quacks like a cookie, and is so far 95%+ effective at laying eggs like a cookie, I’d like to treat it like an unauthorized third party cookie.

I’d like to treat it like an unauthorized third party cookie.

Which we don’t block in WordPress core.

Which leads to the question as to why.
Because unauthorized third party cookies could pretty much just be added through plugins, themes, or hacks, so it wasn’t something that was a generalized risk for which there was a practical solution within Core?
Or because there is something inherently wrong with blocking unauthorized tracking?

The problem behind all these stuffs is economic. Indeed, many websites exists thanks to advertising revenue. What will happen when their earnings will drop?

I think they will all want to disable FLOC to allow their ad agencies to pay them as before. Because I think it’s granted that non-targeted advertising will be less effective.

Plugins can already enable tracking. WordPress does not block that (nor do I believe it should).
Plugins in the WordPress.org repository can also enable tracking, but the Plugin guidelines require that they need to obtain opt-in consent to do so.

May I ask why you believe that, given this, advertising revenue / earnings will drop? Do you not have a plugin enabled that allows you to manage your relationship with your ad agency (whether that is AdSense, or something different)?

Nearly all studies of advertising revenue and how it correlates to 3rd-party cookies (or other tracking mechanisms) show significant drops in revenue. Boston University professor Garrett Johnson has aggregated the studies in a helpful graphic https://twitter.com/garjoh_canuck/status/1331346165623820289.

This is very much our experience running ads across thousands of publishers where CPMs (cost per thousand ads displayed) are 50%+ lower on Safari and Firefox vs Chrome (controlling for other factors). Removing 3PC and not replacing them with another technology will certainly decrease ad spend on the open web and for independent publishers in particular. Those advertisers will move more of their spend into “walled gardens” that have significant logged-in users, like Google O&O (Google.com, Youtube.com), Facebook, Pinterest, Hulu and other services.

FLoC may be flawed, but it certainly will help mitigate the negative impact that ad-supported independent publishers will feel from the end of 3PC.

Welcome to WordPress.org, by the way, @pbannist
Assuming all of what you said above as true:
1. Why is it unreasonable to expect sites (whether ad-supported independent publishers, or others) to opt in to FLoC, via plugin (e.g. a Google Analytics plugin), or by overriding the proposed filter with custom code?
2. Why should the risks be “outsourced” as it were (and most of the benefits “in-sourced”) by demanding involuntary participation from sites who do not / do not want to benefit from FLoC?

Thanks, @Carike nice to be here

In my opinion, for FLoC to be relatively successful, it needs to have ecosystem-wide scale. Clearly, if FLoC only ran on 15 sites it wouldn’t be able to gather enough signals to accurately determine a cohort for users. So things that reduce the scale of FLoC inherently work against its success from an advertising use-case perspective.

Currently, FLoC already is limited to sites that run ad-related resources on them, using the framework here: https://chromium.googlesource.com/chromium/src/+/master/docs/ad_tagging.md. This is meant to be inclusive of publishers who make money via ads, and advertisers, who run ad-related code to understand users on their own properties. By restricting FLoC to only use those sites to define cohorts, I think Chrome has made a smart decision about how to “opt-in” sites.

It stands to reason that most sites that make money from ads or use advertising to grow their business, would want to use technologies like FLoC, and this decision by the Chrome team allows for that. Ad-related sites that don’t want to use FLoC would likely be very clear on how to opt-out. And sites that are not running any ad-related resources would already not be a part of FLoC.

If WordPress were to automatically opt-out all WP sites, the effort of getting hundreds of thousands/millions of sites that have already “expressed” their interest in advertising (via running ad-related resources) would be extremely high and would hinder the scaling requirements of FLoC, thereby making it less useful. This would have a negative impact on the revenues of ad-supported publishers and would drive more advertisers to the “walled gardens” than today, and away from the open web.

And sorry, I didn’t explicitly address your second point, but I don’t think FLoC “outsources” the risks because it only uses sites that are running ad scripts/etc. Therefore the risks/benefits are shared among sites that are on both sides of the system (e.g., they help FLoC gather data, and gain when FLoC works better for advertising)

targeted ads don’t go well with privacy. it’s one way or the other, you cannot have both at the same time.

i agree that a toggle is needed to turn this blocking on or off, so everyone’s happy.

To make sure this is clear, this is personal opinion only, and not meant to represent WP or any other team/group/company.

I agree with folks that have commented that it’s not a security issue, and that it’s not necessary to categorize it that way to backport, if there ends up with consensus on the change.

I’m in favor of WordPress supporting user privacy in the general sense, whether it be through actions like the one proposed, or through discussions like the one that is happening. Maybe the conversation happening will mean that instead something can be worked out / improved without this action.

As it stands, with my current understanding on how FLoC works, I’m in favor of blocking, and backporting, to prevent further tracking of users without their approval. I think that supporting users on the web is more important than protecting ad tech. Users are currently not aware that they would need to stop using a particular browser to opt out of this technology, so I don’t think it *is* a choice they’re making. Tracking should be opt-in, not opt-out.

I hope the decision won’t be “is this kind of tracking better than the other one” — like the EFF article mentions, “Instead of re-inventing the tracking wheel, we should imagine a better world without the myriad problems of targeted ads.”

In either case, I’m looking forward to the deeper discussion and willing to have my mind changed. Thanks for bringing this up, @carike!

I completely agree with @mikeschroder!

The default is just wrong (among others).

When I set up a WordPress site right now, I choose explicitly and consciously whether I want to enable tracking and third-party cookies. With FLoC in its current state, this won’t be the case unless WordPress (or Google) sets opt-out as a default.

Grouping people, targeting them and trying to change their behaviour has several unforeseeable (negative) effects, no open source project should support this, or allow this as a default.

And indeed:

“Instead of re-inventing the tracking wheel, we should imagine a better world without the myriad problems of targeted ads.”

Well put @mikeschroder. Indeed this is not necessarily a security issue, however as a privacy issue I believe that it is still of high importance.

I think user privacy should be a priority for WordPress and although this isn’t necessarily a security issues it would be nice to see it back-ported. As a privacy conscientious developer, the proposal has my support and disabling FLoC by default is the correct thing to do, especially since most users are unlikely to be aware of FLoC (something I believe it in fact relies on).

This technology does not in any way exist to benefit the average WordPress user and I have no doubt that there will be numerous ways of re-enabling it (both officially or otherwise) if there are users who need this tech to be used on their website.

I think the EFF has made a good case against it by outlining the many potential problems that can result in this kind of targeted advertising.

FYI: As commented on this week’s dev chat agenda post, representatives from the Chrome team will be joining the next dev chat to discuss and answer questions.

The reason why FLoC is worse than traditional cookies, is because individual sites can decide not to set cookies. For example, I choose not to track my users and I don’t put any cookies on their browser.

FLoC is one giant 3rd party cookie that’s applied by default to all websites. To opt-out, you need to make a change to your site. That’s a massive violation of trust IMHO. If at all, it should be opt-in not opt-out.

Honestly, this is basically malware in Chrome. The only reason why we’re not seeing it that way, is because it’s Google, and we don’t assume that Google will put “malware” on their browser. But if anyone else had tried this, it would be blocked immediately.

I see the reasoning behind not wanting to mark it as a security update. But I can see the other side as well? It sort of is a security issue!

First of all I’m glad that the misunderstanding about this being a “security concern” was resolved (this is not security related but can be added to a minor WP release just like a major bugfix or a security fix).

Reading through all the comments and references, an interesting fact is that (currently) FLoC is not being used/tested in Europe. From the info so far it seems that for FLoC to be used in countries where user privacy is protected by the GDPR, web sites will have to display info about it and have some sort of opt-in mechanism (same thing like for cookies when you’re in Europe).

If the above assumption is correct, the FLoC API will have to support opt-in by the site visitors before any data can be used or stored, or it will not comply with the GDPR. For WordPress this adds the possibility to have such “opt-in dialog box” by default.

I think this will depend – if GDPR decides that FLoC is “suitably anonymized” then no, I don’t think a user opt-in would need to be collected. The legislation wasn’t designed with FLoC in mind, rather the other way around, is my read.

The header would say “don’t use this website for FLoC” which is a decision a webmaster should be able to make pro-actively on behalf of their community of users.

The question at hand, is if we should make this the default choice in WordPress — if we think WordPress core should incorporate Privacy by Design into our software, then we probably should do that, and allow those who wish to opt their community in, to do so.

I liken this to the option to add robots “noindex” meta tag under settings to “discourage” search engines from indexing the site.

Why don’t we add the noindex meta by default? Because the act of publishing a public website allows us to assume the webmaster would like to be indexed, but to give them the option of disabling this.

With FLoC the assumption is probably the reverse, because the question is: would you like for your website’s visitors to be automatically opted in to become a part of a cohort based on their visit to this website?

I think the assumption can be that most webmasters would not – therefore, it should be a positive action to opt your visitors in, rather than the reverse – an probably more so while the technology is nascent.

Email Updates

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 4,899 other subscribers

Email Address

Current Release

The current release in progress is WordPress 5.8.

Planned future releases are listed on the Project Roadmap.

Feature projects not tied to specific releases can be found on the Features page.

Team Pledges

974 people have pledged time to contribute to Core Team efforts! When looking for help on a project or program, try starting by reaching out to them!

So What Now?

What About Admins Who Want FLoC?

What Do You Mean By “Treat It Like A Security Concern”?

Why Treat It That Way? Why Not Just Wait For The Next Major Release?

Request For Comment

Email Updates

Current Release

Team Pledges

Recommend

Rack apps mounted in Rails — how to protect access to them?

陀螺产业区块链第十一季 | 区块链乡村振兴一体化平台

ETF 逐渐登场，比特币2021年加速向传统世界进军

Injecting extra data in the payload of queued jobs in Laravel

九州云箭完成过亿元A轮系列融资专注液氧甲烷火箭发动机制造

数美科技宣布完成1.35亿美元融资累计保护全球用户超过30亿

Controlling the flow of time in your tests

Ampleforth 治理代币 FORTH 空投领取教程

摩根大通：比特币的流动性将逐渐恢复并保持强劲

疑似“碰瓷”博鳌论坛的除了蒙牛，还有海马汽车、神州专车

About Joyk