[wp-trac] [WordPress Trac] #52903: Consent Management within WordPress Core

[WordPress Trac]

#52903: Consent Management within WordPress Core
-------------------------+-------------------------------------------------
 Reporter:  carike       |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Privacy      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  ui, accessibility, javascript,
                         |  administration, rest-api
-------------------------+-------------------------------------------------
Description changed by carike:

Old description:

> **Website visitor / user Privacy choices:**
>
> a. 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.
>
> b. 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
> <?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
> <?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
> <?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
> <?php
> $consent = array("functional" => TRUE, "preferences" => TRUE,
> "anon_stats" => TRUE, "stats" => TRUE, "marketing" => TRUE);
> return $consent;
> }}}
>

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

New description:

 **Website visitor / user Privacy choices:**

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

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

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52903#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform