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

[WordPress Trac]

#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
----------------------------------+----------------------
Description changed by carike:

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

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.

 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.

 Example 1:

 The website offers a newsletter, but also wants user permission for third
 party targeted advertising on the website. The site owner does not want to
 exclude everyone who opts out of the latter from receiving their
 newsletter.
 The website offers notifications. The site owner / admin does not wish to
 exclude someone from setting their preferred admin colour scheme if they
 do not wish to consent to notifications.

 {{{#!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.

 Example 2:

 This shows a use case for which one additional top-level consent type (not
 exposed to the front end, only available on /wp-admin/) would be very
 useful.
 Plugin authors are currently allowed to advertise / provide notices, as
 long as they don't hijack the admin panel.
 One of the most common ways to permanently dismiss a notice is to add a
 user_meta value for it - which isn't the best use of the database / ideal
 for performance.

 The below may allow for theme authors to be able to provide installation /
 setup instructions via admin notifications as well. This ticket only shows
 a possible way it could be done. All discussion about the theme guidelines
 themselves should happen during Team meetings and on the relevant P2
 posts.
 In this example, the notice has not yet been permanently dismissed. Once
 the notice has been permanently dismissed for that user, the boolean value
 for that theme under "repos" should be set to "false".

 {{{#!php
 <?php
 $consents = array(
    'functional' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'preferences' => array(
       'comprehensive' => false,
       'remainder' => true
    ),
    'anon_stats' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'stats' => array(
       'comprehensive' => false,
       'remainder' => false
    ),
    'marketing' => array(
       'comprehensive' => false,
       'remainder' => true
    ),
    'repos' => array(
       'comprehensive' => false,
       'exampleTheme" => true,
       'remainder' => 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.

--

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