Consent Management within WordPress Core

[carike]

Website visitor / user Privacy choices:

1. Users who are not registered on a site, or who choose not to log in when prompted, can set their consent preferences via a simple banner (Gutenberg block) on the front end, which will set a (functional) cookie value for consent.

It should be possible for plugins to filter the banner contents and to change the appearance.

2. Registered users can set their consent preferences via an interface in wp-admin, after logging in.

The interface should extend the "Edit Profile" page.

Once a registered user logs out, the consent cookie value should be updated to reflect their preferences as per the database (sync).

(Sane) Defaults:

Five default consent categories have been proposed: Functional; Preferences; Anonymous Analytics; Analytics and Marketing.

Website owners / admins should be able to set site-wide defaults by setting a site option value, or by using a plugin to do so.
[An alternative would be to allow them to do so via filter.]

It should be possible for site owners / admins to add additional consent categories, or to add nested sub-categories, or to allow a plugin to do so.

As privacy legislation varies across the globe, I believe that WordPress should default to TRUE for each category, if not overridden, to maintain backwards compatibility and avoid unexpected behaviour.

Proposed Consent Management hierarchy:

1. If the user is logged in and has set consent preferences, obtain their preferences via an extension of the REST API.

Using the REST API will allow us to cater for cookies that are set in JavaScript, rather than in PHP.

The basic logic:

<?php
$user_id = get_current_user_id();
if (is_user_logged_in() === TRUE) { $consent = get_user_meta($user_id, 'consent_preferences', FALSE); }
if ( $consent !== NULL ) { return $consent; }

2. If the user is logged out and has set consent preferences in a (functional) cookie, obtain the (functional) cookie consent value.

The basic logic:

<?php
if ( isset($_COOKIE['consent_cookie']) ) { return $_COOKIE['consent_cookie']; }

3. If the user has not set consent preferences, obtain the site privacy defaults from a site option value.

The basic logic:

<?php
$consent = get_option('site_consent_preferences');
if ($consent !== FALSE) { return $consent; }

4. Otherwise, return WordPress defaults - i.e. an associative array where the default values are TRUE.

The basic logic:

<?php
$consent = array("functional" => TRUE, "preferences" => TRUE, "anon_stats" => TRUE, "stats" => TRUE, "marketing" => TRUE);
return $consent;

How to integrate all of this into the Developer community:

This would require a number of approaches and mechanisms, including:

New functions:

Creating a wp_setcookie(); function in PHP and a corresponding function in JavaScript that checks for consent before placing a cookie;
Use of wp_setcookie(); can then be required for new plugin submissions to the WordPress.org repository.

Updating existing functions:

Updating other functions like wp_mail(); and the HTTP and REST APIs to check for the appropriate consent.
In the case of wp_mail(); for example, this can be done by adding a new parameter variable for $consent_purpose.
We can add a _doing_it_wrong(); if this variable is not present.
In the case of the REST API, consent could possibly be integrated into a permission callback, but that is something we'd need Timothy's (and others) input on.

Education drive:

Voluntary compliance is preferred. By providing documentation, resources and discussing with as many stakeholders as we can (primarily on Slack), we can encourage adoption through education.

Related tickets:

I will be closing #51188 in favour of this ticket to make it easier for new contributors to get involved. Please do feel welcome to read the closed ticket if you need / want background.
#51110 deals with the design of a wp-admin interface.
There is not a ticket for the design of a Gutenberg block (as a front end "interface") yet.

[ryokuhi]

This ticket was checked a few times in the last weeks during the accessibility team's bug-scrubs.
While we would be happy to contribute and make sure that the new feature is accessible from the beginning, until there's something to review our team can't really help with moving this ticket forward.
Maybe it might be better to assign an owner to this ticket and move it to Future Release, so it doesn't pop up whenever we go through the queue of the Awaiting Review tickets: we'll start reviewing this ticket when it'll be milestoned for a specific release.

[ryokuhi]

As there was no movement on this ticket in the last few months and we don't really have anything to review for accessibility issues at the moment, I'm removing the accessibility focus.

Feel free to add it back once there is at least a mocukp or a first draft of the implementation.

[desrosj]

#56278 was marked as a duplicate.

[jorbin]

#56828 was marked as a duplicate.