Consider implications of FLoC and any actions to be taken on the provider (WordPress) front

[helen]

This is a tracking ticket to recognize the ​FLoC project and Origin Trial, monitor its progress, and discuss any actions that WordPress core should take and the implementation details of such. "Provider" refers to the side that is serving the site (CMS, publisher, site admin, etc.) and "consumer" refers to the side viewing the site (browser, reader, etc.).

For a high-level overview, FLoC (Federated Learning of Cohorts) is a Chrome-based initiative to calculate a cohort (henceforth referred to as "bucket") on the browser side for a user based on their browsing activity. It is meant as a replacement for third-party cookies typically used for ad targeting, providing what is supposed to be a somewhat more anonymous bucket of thousands of users to serve as a target rather than you as an individual. It is currently in an "origin trial" phase, in which some users are opted in via their usage of Chrome.

The current stated intention is for sites not to be included in the calculation of which bucket a user/browser instance is assigned to unless they specifically call the FLoC API or contain ​ad resources, noting that third-party JS, such as may come with an oEmbed, can also call the FLoC API and cause a page/site to be included in the calculation. Sites can explicitly opt-out of being included in calculations regardless of the content by sending a header. Whether this current intention remains true is one item to be monitored.

Some things that likely need discussion include but are certainly not limited to:

• At what stage of the FLoC trial should WordPress consider taking any action?
• What level of user education should WordPress provide, either in-admin or beyond? Does this education need to extend to general advice on how to vet third-party embeds which are a potential entry point?
• If WordPress were to send the explicit opt-out header by default, what sort of impact would this have on individual users (both providers and consumers) and ad/targeting technology at large?
• What is the benefit of a broad provider-level opt-out versus the existing consumer opt-out?
• How are folks thinking of opt-in vs. opt-out, since you could consider this opting out of using a technology or enforcing an opt-in only model?

[robscott]

Thanks for listing this here @helen - I was sorry I couldn't make the core dev chat, but caught up with it on Slack.

This statement:

"If WordPress were to send the explicit opt-out header by default, what sort of impact would this have on individual users (both providers and consumers) and ad/targeting technology at large?"

I think we don't need to consider this to be a be-all and end-all "we've opted everyone in WordPress in or out!" Situation. A core setting, similar in nature to the robots meta opt-out, would be an enhancement, empowering webmaster to make decision for themselves?

The question then would be if we would opt out by default - but I don't see why (should the experiment move to production) we shouldn't empower WP website owners to make this decision without having to use a filter to add the header.

Is it plugin territory? Well, for me it fits with Privacy settings, regardless of political stance, we don't need to take a view: some people want to disable it, we should enable them to make this decision.

[jorbin]

@robscott In general, WordPress is very hesitant to add new options. It's a part of the ​WordPress Philosophies which specifically state "Decisions not Options".

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

This philosophy point is fairly influenced by the writing of Havoc Pennington, the two essays of value here are ​https://ometer.com/preferences.html and ​https://ometer.com/free-software-ui.html

[robscott]

Replying to jorbin:

@robscott In general, WordPress is very hesitant to add new options. It's a part of the ​WordPress Philosophies which specifically state "Decisions not Options".

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

This philosophy point is fairly influenced by the writing of Havoc Pennington, the two essays of value here are ​https://ometer.com/preferences.html and ​https://ometer.com/free-software-ui.html

Understood, hence my use of the word decision in this statement: "empowering webmaster to make decision for themselves" - adding a filter to add an HTTP header to the website is not a decision most people who run WP sites can make (without a developer) and hence, it's valid privacy control; adding the header (or not adding the header) would seem to be taking the decision away from the majority of website owners?

[jorbin]

Yes, the point of this philosophy is so that site owners shouldn't need to make decisions, especially around technical concepts that they won't fully understand.

[robscott]

Yes I get it - I'm saying it's not a technical question - it's a Privacy Control.

"Would you like to opt your site out of FLoC?" - we're designing software for the majority... aren't we?

[vimes1984]

As per this:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.
from here: ​https://wordpress.org/about/philosophy/

I'd agree with Robin here this isn't a technical decision it's a question of privacy, so by offering an option we aren't "putting the weight of technical choices on our end users" we ARE and should put the weight of privacy choices on our end users though... Whether we choose to opt-in OR opt-out is a different discussion but the user SHOULD be made aware this isn't a technical decision. How that option then represents itself is a technical decision we shouldn't be asking them, do you want to opt out via Javascript or HTTP headers....

But I'd strongly advocate for giving the user the ability to opt in or out on the end user not us...

[rachelnorfolk]

FYI adding the headers by default is now committed to Drupal core: ​https://www.drupal.org/project/drupal/issues/3209628

[roytanck]

In many ways, this is an unprecedented situation. It's not every day that a built-in, on-by-default browser feature is introduced. And in this case it's a feature that actively harms visitor privacy for the benefit of ad tech companies.

Instead fo comparing FLoC to its predecessor, third party cookies, I feel it's actually more like the Facebook Pixel. Mostly in the sense that it's controlled by a single surveilance capital company. FLoC may not be quite as nefarious, but I feel it should be something website owners conciously opt in to.

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

I feel like adding the HTTP header is currently mostly a political statement. It's a project/website's way of voicing our concern about the trial. In its current state, I support blocking FLoC by default. If the eventual implementation of FLoC warrants it, we can revert back to an opt-out option in whatever the following release is at that point.

[dmccan]

"At what stage of the FLoC trial should WordPress consider taking any action?"

As soon as possible. One of the things that is broken about the Internet is user tracking and the loss of privacy. When given the choice, users opt-out of tracking. Here is an article reporting that 96% of US users opt-out of app tracking on their iPhones when given a choice:

​https://arstechnica.com/gadgets/2021/05/96-of-us-users-opt-out-of-app-tracking-in-ios-14-5-analytics-find/

Companies have already shown themselves adept at piecing together data from different sources to identify users. There is no track record showing this to be any different. If after a few years Google is able to show that FLoC can enable targeted advertising without eroding user privacy then WordPress can reconsider.

"What is the benefit of a broad provider-level opt-out versus the existing consumer opt-out?"

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

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

(Should that be "end user" instead of "consumer"?)

[hellofromTonya]

With 5.8 Beta 1 happening today and ongoing discussions, time has run out for this ticket to land in 5.8. Punting to Future Release. Once there's consensus, please move into a future milestone.

[paapst]

Since the Floc experiment and development has ended in July 2021, further development outside WP now seems to focus on other initiatives such as the ​Topics API. I would therefore suggest closing this ticket. If needed the Topics API can be discussed in #core-privacy, in #core, or in a new Trac ticket.