[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.
>
> 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' => [
>    'functional' => [
>       'comprehensive' => false
>    ],
>    'preferences' => [
>       'comprehensive' => true
>    ],
>    'anon_stats' => [
>      'comprehensive' => true
>    ],
>    'stats' => [
>       'comprehensive' => false
>    ],
>    'marketing' => [
>       '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.

 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' => [
    'functional' => [
       'comprehensive' => true
    ],
    'preferences' => [
       'comprehensive' => true
    ],
    'anon_stats' => [
      'comprehensive' => true
    ],
    'stats' => [
       'comprehensive' => false
    ],
    'marketing' => [
       '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.

--

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