[wp-trac] [WordPress Trac] #51188: Website user level consent management framework (logged in users) (was: Create a structure for consent-related user meta value)

[WordPress Trac]

#51188: Website user level consent management framework (logged in users)
-----------------------------+---------------------
 Reporter:  carike           |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  5.6
Component:  Privacy          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+---------------------

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

New description:

 **Background:**

 The Consent API is an initiative that is currently underway in the Privacy
 team.
 The code is available in the plugin repository here:
 https://wordpress.org/plugins/wp-consent-api/
 The Feature Plugin proposal is here:
 https://make.wordpress.org/core/2020/04/01/feature-plugin-proposal-wp-
 consent-api/
 While there has been a strong consensus for a long time that a consent
 management framework is necessary in Core, the Team is still building
 consensus on what the implementation should look like.
 One of the disagreements with the proposed feature plugin implementation,
 is that consent choices made by website users are not going to be reliably
 available if they are saved in a cookie, because the cookie may expire, or
 more likely, be cleared.
 While this is an inherent limitation for users who are not logged in, it
 is not necessary to subject registered users who are logged in to notice
 fatigue.
 More information here: https://make.wordpress.org/core/2020/08/22/request-
 for-input-consent-preferences-for-logged-in-users-consent-api/
 In short, it is possible to save the registered users' consent choices in
 the database.

 **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 Website User Level Consent
 Management.

 List of milestones:

 This ticket seeks to answer the following design questions:
 {{{#!php
 <?php
 1. Which consent categories should be available by default?
 2. Should plugins be able to add additional consent categories?
 3. If yes to the above, should these be new top-level consent categories,
 or sub consent categories, or a nested hierarchy of both?
 }}}

 It does this by dealing 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 plugin (proposed feature plugin)
 allows for these 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.
 One of the WordPress Core Coding Philosophies is extendibility.
 We should not limit the usefulness of this long anticipated Core feature /
 benefit only a handful of plugins.

 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.
 This would avoid the need for expensive database upgrades.
 The Website User Level Consent Manager would fall back to site defaults if
 no meta value exists for the user.

 It should be possible to create a hook that would allow for the logging of
 changes in consent (i.e. when the consent user_meta value is updated).

 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.

 Example 3:

 This shows a use-case where the website owner needs to cater for
 legislative consent requirements from various jurisdictions.

 In this example, the website owner would still like to be able to send
 first party marketing to website users who choose to opt-out of the sale
 of their data i.t.o. the CCPA.

 {{{#!php
 <?php
 $consents = array(
    'functional' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'preferences' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'anon_stats' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'stats' => array(
       'comprehensive' => true,
       'remainder' => true
    ),
    'marketing' => array(
       'comprehensive' => false,
       'sell_data' => false,
       'remainder' => true
    )
 );
 }}}

 **Acknowledgements:**

 Thanks to Rogier for defining the initial 5 categories with input from the
 privacy team.
 Thanks to Paapst for the heads-up that consent needs to be re-confirmed if
 new cookies are added.
 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):

 Changed from a milestone for the Consent API to a milestone for Website
 User Level Consent Management as per the request from @paapst in
 https://core.trac.wordpress.org/ticket/51188#comment:16

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