[wp-trac] [WordPress Trac] #51188: Create a structure for consent-related user meta value

Sun Aug 30 13:38:57 UTC 2020

#51188: Create a structure for consent-related user meta value
----------------------------------+----------------------
 Reporter:  carike                |       Owner:  (none)
     Type:  enhancement           |      Status:  new
 Priority:  normal                |   Milestone:  5.6
Component:  Privacy               |     Version:  trunk
 Severity:  normal                |  Resolution:
 Keywords:  needs-privacy-review  |     Focuses:  privacy
----------------------------------+----------------------

Old description:

> **Background:**
>
> The Consent API is an initiative that is currently underway in the
> Privacy team.
> The code is available in the repository here:
> https://wordpress.org/plugins/wp-consent-api/
> More information here: https://make.wordpress.org/core/2020/08/22
> /request-for-input-consent-preferences-for-logged-in-users-consent-api/
>
> **The Challenge:**
>
> Cookies are inherently transient in nature.
> In order to make consent choices persistent, user consent choices need to
> be saved in the database.
> This is only possible for users who are registered and logged in.
>
> **The Scope:**
> This ticket represents a milestone for the Consent API.
>
> List of milestones:
>
> This ticket deals only with the user meta value that is needed to save
> privacy choices for registered users. Users who are not logged in, or who
> are not registered, need to be dealt with differently and will be
> addressed in other tickets.
> This ticket only proposes a nested hierarchy and does not explore the
> necessary validation / sanitization to add consent types, or escaping the
> output.
> [] will be created to create a hook to allow for the logging of consent
> by plugins.
> #51110 proposes a registered website user-level privacy UI.
>
> **The Solution:**
>
> In its current form the Consent API allow for five consent categories:
> 1. Functional;
> 2. Preferences;
> 3. Anonymous Statistics;
> 4. Statistics;
> 5. Marketing.
>
> Adding too many consent types would make it unwieldy and unnecessarily
> complicated for website visitors.
> However, there are certainly use cases in which site owners / admins may
> need more granular control.
> Let's say, for example, that the website offers a newsletter, but also
> wants user permission for third party targeted advertising on the
> website. The site owner may not want to exclude everyone who opts out of
> the latter from receiving their newsletter.
>
> It seems that the best way to do this would be to provide a function in
> Core that would allow plugins to register **sub**-consent types.
>
> It seems desirable to let site owners / admins determine default consent
> values - or to install a plugin to do so, for example, based on the
> visitor's location and the site's host's location.
>
> It does not seem desirable to create a consent meta value for the user as
> soon as the user is created - instead, a consent user meta value should
> only be created once the registered user has explicitly indicated their
> choice.
> It should be possible to create a hook that would allow for the logging
> of changes in consent.
>
> It does not seem desirable to save multiple user_meta values relating to
> consent per user, for performance reasons.
> A possible model might look something like the meta value for user
> capabilities.
>
> {{{#!php
> <?php
> $consents = array(
>    'functional' => array(
>       'comprehensive' => true
>    ),
>    'preferences' => array(
>       'comprehensive' => true
>    ),
>    'anon_stats' => array(
>      'comprehensive' => true
>    ),
>    'stats' => array(
>       'comprehensive' => false
>    ),
>    'marketing' => array(
>       'comprehensive' => false,
>       'newsletter' => true,
>       'targeted_ads' => false
>    )
> );
> }}}
>
> The above should be appropriately serialized before being saved to the
> database.
>
> **Acknowledgements:**
>
> Thanks to Rogier for defining the initial 5 categories with input from
> the privacy team.
> Thanks to Retrofitter for inquiring about additional consent categories
> on P2.
> Thanks to Jono for input on a nested structure for consent.

New description:

 **Background:**

 The Consent API is an initiative that is currently underway in the Privacy
 team.
 The code is available in the repository here:
 https://wordpress.org/plugins/wp-consent-api/
 More information here: https://make.wordpress.org/core/2020/08/22/request-
 for-input-consent-preferences-for-logged-in-users-consent-api/

 **The Challenge:**

 Cookies are inherently transient in nature.
 In order to make consent choices persistent, user consent choices need to
 be saved in the database.
 This is only possible for users who are registered and logged in.

 **The Scope:**
 This ticket represents a milestone for the Consent API.

 List of milestones:

 This ticket deals only with the user meta value that is needed to save
 privacy choices for registered users. Users who are not logged in, or who
 are not registered, need to be dealt with differently and will be
 addressed in other tickets.
 This ticket only proposes a nested hierarchy and does not explore the
 necessary validation / sanitization to add consent types, or escaping the
 output.
 [] will be created to create a hook to allow for the logging of consent by
 plugins.
 #51110 proposes a registered website user-level privacy UI.

 **The Solution:**

 In its current form the Consent API allow for five consent categories:
 1. Functional;
 2. Preferences;
 3. Anonymous Statistics;
 4. Statistics;
 5. Marketing.

 Adding too many consent types would make it unwieldy and unnecessarily
 complicated for website visitors.
 However, there are certainly use cases in which site owners / admins may
 need more granular control.
 Let's say, for example, that the website offers a newsletter, but also
 wants user permission for third party targeted advertising on the website.
 The site owner may not want to exclude everyone who opts out of the latter
 from receiving their newsletter.
 Another possible use case may be notifications. A site owner / admin may
 not wish to exclude someone from setting their preferred admin colour
 scheme if they do not wish to consent to notifications.

 It seems that the best way to do this would be to provide a function in
 Core that would allow plugins to register **sub**-consent types.

 It seems desirable to let site owners / admins determine default consent
 values - or to install a plugin to do so, for example, based on the
 visitor's location and the site's host's location.

 It does not seem desirable to create a consent meta value for the user as
 soon as the user is created - instead, a consent user meta value should
 only be created once the registered user has explicitly indicated their
 choice.
 It should be possible to create a hook that would allow for the logging of
 changes in consent.

 It does not seem desirable to save multiple user_meta values relating to
 consent per user, for performance reasons.
 A possible model might look something like the meta value for user
 capabilities.

 {{{#!php
 <?php
 $consents = array(
    'functional' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'preferences' => array(
       'comprehensive' => false,
       'notifications' => array(
          'all' => false,
          'daily' => false,
          'weekly' => true,
          'monthly' => false,
          'none' => false,
       ),
       'remainder' => true
    ),
    'anon_stats' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'stats' => array(
       'comprehensive' => false,
       'remainder' => false
    ),
    'marketing' => array(
       'comprehensive' => false,
       'newsletter' => true,
       'targeted_ads' => false,
       'remainder' => true
    )
 );
 }}}

 The above should be appropriately serialized before being saved to the
 database.

 **Acknowledgements:**

 Thanks to Rogier for defining the initial 5 categories with input from the
 privacy team.
 Thanks to Retrofitter for inquiring about additional consent categories on
 P2.
 Thanks to Jono for input on a nested structure for consent.

--

Comment (by carike):

 > The only use case that is being mentioned here (the offering of a
 newsletter) will actually not make use of the Consent API.

 Not as per current compliance / newsletter plugins, but it is definitely a
 conceivable use case.
 One of the core WordPress coding philosophies is extend-ability.
 We should leave room for developers to innovate, while still respecting
 user's consent choices.

 > All the other use cases I can think of, all make use of the 5 initial
 purposes.

 Let's say a site hosts third party videos and offers their registered
 users the option to subscribe to notifications.
 But some of these third parties upload ten or fifteen videos a day and
 this is causing all sorts of issues like e-mails being marked as spam
 because of the high volume of very similar messages - so they want to give
 users the ability to have more granular control over their notifications,
 rather than simply have an AI decide their preferences for them.
 This isn't quite marketing and it isn't quite functional. I'd personally
 regard notifications as preferences, but regardless of the classification,
 a nested hierarchy makes a Consent API much more useful.

 We should be future-proofing this feature.

 > Adding sub-consent types and a nested hierarchy will only add extra
 complexity to the API and to core .

 Could you perhaps give a practical example of this?
 I do not see how a nested hierarchy would be incrementally significantly
 more complex than an array of only five consent types - as there already
 need to be functions to alter the boolean values for the five consent
 types (add / remove consent), as well as to retrieve a consent value - and
 the meta value for caps in the db already present a nested hierarchy, but
 I may be missing something?

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