Changes between Version 7 and Version 18 of Ticket #51188
- Timestamp:
- 09/06/2020 03:56:58 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #51188
- Property Focuses privacy removed
-
Property
Summary
changed from
Create a structure for consent-related user meta valuetoWebsite user level consent management framework (logged in users) -
Property
Version
changed from
trunkto - Property Keywords needs-privacy-review removed
-
Property
Type
changed from
enhancementtofeature request
-
Ticket #51188 – Description
v7 v18 2 2 3 3 The Consent API is an initiative that is currently underway in the Privacy team. 4 The code is available in the repository here: https://wordpress.org/plugins/wp-consent-api/ 4 The code is available in the plugin repository here: https://wordpress.org/plugins/wp-consent-api/ 5 The Feature Plugin proposal is here: https://make.wordpress.org/core/2020/04/01/feature-plugin-proposal-wp-consent-api/ 6 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. 7 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. 8 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. 5 9 More information here: https://make.wordpress.org/core/2020/08/22/request-for-input-consent-preferences-for-logged-in-users-consent-api/ 10 In short, it is possible to save the registered users' consent choices in the database. 6 11 7 12 **The Challenge:** … … 12 17 13 18 **The Scope:** 14 This ticket represents a milestone for the Consent API.19 This ticket represents a milestone for Website User Level Consent Management. 15 20 16 21 List of milestones: 17 22 18 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. 23 This ticket seeks to answer the following design questions: 24 {{{#!php 25 <?php 26 1. Which consent categories should be available by default? 27 2. Should plugins be able to add additional consent categories? 28 3. If yes to the above, should these be new top-level consent categories, 29 or sub consent categories, or a nested hierarchy of both? 30 }}} 31 32 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. 19 33 This ticket only proposes a nested hierarchy and does not explore the necessary validation / sanitization to add consent types, or escaping the output. 34 20 35 [] will be created to create a hook to allow for the logging of consent by plugins. 21 36 #51110 proposes a registered website user-level privacy UI. … … 23 38 **The Solution:** 24 39 25 In its current form the Consent API allow forfive consent categories:40 In its current form the Consent API plugin (proposed feature plugin) allows for these five consent categories: 26 41 1. Functional; 27 42 2. Preferences; … … 32 47 Adding too many consent types would make it unwieldy and unnecessarily complicated for website visitors. 33 48 However, there are certainly use cases in which site owners / admins may need more granular control. 49 One of the WordPress Core Coding Philosophies is extendibility. 50 We should not limit the usefulness of this long anticipated Core feature / benefit only a handful of plugins. 34 51 35 52 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. … … 38 55 39 56 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. 40 It should be possible to create a hook that would allow for the logging of changes in consent. 57 This would avoid the need for expensive database upgrades. 58 The Website User Level Consent Manager would fall back to site defaults if no meta value exists for the user. 59 60 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). 41 61 42 62 It does not seem desirable to save multiple user_meta values relating to consent per user, for performance reasons. … … 127 147 The above should be appropriately serialized before being saved to the database. 128 148 149 Example 3: 150 151 This shows a use-case where the website owner needs to cater for legislative consent requirements from various jurisdictions. 152 153 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. 154 155 {{{#!php 156 <?php 157 $consents = array( 158 'functional' => array( 159 'comprehensive' => true, 160 'remainder' => true 161 ), 162 'preferences' => array( 163 'comprehensive' => true, 164 'remainder' => true 165 ), 166 'anon_stats' => array( 167 'comprehensive' => true, 168 'remainder' => true 169 ), 170 'stats' => array( 171 'comprehensive' => true, 172 'remainder' => true 173 ), 174 'marketing' => array( 175 'comprehensive' => false, 176 'sell_data' => false, 177 'remainder' => true 178 ) 179 ); 180 }}} 181 129 182 **Acknowledgements:** 130 183 131 184 Thanks to Rogier for defining the initial 5 categories with input from the privacy team. 185 Thanks to Paapst for the heads-up that consent needs to be re-confirmed if new cookies are added. 132 186 Thanks to Retrofitter for inquiring about additional consent categories on P2. 133 187 Thanks to Jono for input on a nested structure for consent.