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

[WordPress Trac]

#52903: Consent Management within WordPress Core
-------------------------------------------------+-------------------------
 Reporter:  carike                               |      Owner:  (none)
     Type:  feature request                      |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  Privacy                              |    Version:
 Severity:  normal                               |   Keywords:  needs-patch
  Focuses:  ui, accessibility, javascript,       |
  administration, rest-api                       |
-------------------------------------------------+-------------------------
 **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.

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