WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 2 weeks ago

#53069 new task (blessed)

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

Reported by: helen Owned by:
Milestone: 5.8 Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: privacy Cc:

Description (last modified by westonruter)

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?

Change History (7)

#1 @westonruter
3 weeks ago

  • Description modified (diff)

#2 @robscott
2 weeks ago

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.

Last edited 2 weeks ago by robscott (previous) (diff)

#3 follow-up: @jorbin
2 weeks ago

@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

#4 in reply to: ↑ 3 @robscott
2 weeks ago

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?

Last edited 2 weeks ago by robscott (previous) (diff)

#5 @jorbin
2 weeks ago

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.

#6 @robscott
2 weeks ago

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?

Last edited 2 weeks ago by robscott (previous) (diff)

#7 @vimes1984
2 weeks ago

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 it's self 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...

Version 0, edited 2 weeks ago by vimes1984 (next)
Note: See TracTickets for help on using tickets.