[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:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  5.6
Component:  Privacy          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+---------------------

Comment (by carike):

 Replying to [comment:11 azaozz]:

 > > Users who need to give consent can be registered users who are logged
 in, registered users who are not logged in, or website visitors who are
 not registered.
 >
 > Think this doesn't sound right. In WP (and on most websites) there are
 no "registered users who are not logged in". These people are treated as
 "visitors" to the site, have no access to any special areas, and are not
 exposed to anything more that "standard" visitors.

 Consent preferences for registered users should be saved in the DB, as per
 our P2 discussion and the preceding #core-privacy discussions.
 Consent preferences for users who are not registered cannot be saved in
 the DB, so these need to be saved in cookies, which are inherently
 transient in nature.
 When registered users are not logged in, there is no way to distinguish
 them from visitors who are not registered, so their consent preferences
 are determined by cookies when logged out.

 **However**, registered users should be able to set their consent
 preferences for when they are logged out in the same /wp-admin/ UI that
 they are able to set their consent preferences for while they are logged
 in. I.e. they should be able to view and update their consent-related
 cookie values from inside their profile page.
 This is why they constitute a third group - because something "extra" is
 needed for their UI.
 The distinction is simply a matter of convenience.

 > In that terms there are two groups of people that should be asked for
 consent:
 > - Logged-in (registered) users that are not site-owners/admins. This may
 include people that are buying something from an online store, however
 afaik the requirements there are different and a "consent API" will
 probably not work for these cases.

 Users who are logged in to your membership site (for example, this applies
 to any site, including e-commerce) still need to be asked for their
 consent to track them, for statistical or marketing purposes.
 e-Commerce stores should, as a matter of best practice, ask their users to
 accept their product terms, but that does not affect the fact that the
 above still applies.

 > - Site visitors.
 >
 > > (The Consent API could conceivably serve the needs of the repos as
 well, in which case the site admins would be the ones denying consent, but
 that would be a secondary, complementary purpose.)
 >
 > Sorry but not sure I understand what you mean. What repos? Do you mean
 trac and github? How these have anything to do with a production install
 of WP? Also what does it mean for a site admin to "deny consent"? What
 happens then? The visitor is "thrown out" of the website?

 Here I am referring to the WP plugin repository and theme directory.
 There have been a lot of issues with developers upselling in /wp-admin/
 and the Consent API could conceivably be used to ensure that ads in the
 admin area are permanently dismiss-able without cluttering up the DB with
 multiple user_meta values or transients.
 However, as I indicated, this would not be a primary purpose, simply a
 possible perk.

 > > Those who need to ask for consent are effectively the plugin
 developers...
 >
 > I think this is incorrect. Plugin authors should disclose what their
 plugins do or use, but the people that need to ask for consent are the
 site owners. Could you please double check this with somebody with a
 law/legal background (perhaps other member of the privacy team)?

 Yes, the site owners are the ones who are responsible.
 But they are not the ones actually writing the code.
 So, the plugin authors are the ones that need to make use of
 wp_setcookie() [or its yet-to-be-determined JavaScript equivalent]. So
 effectively / in practice, their code is asking consent **on behalf of**
 the site owner.

 > Also, some "software development housekeeping": Generally trying to
 determine some kind of format to store some kind of data in some
 (undecided) place without knowing how that data is going to be used is a
 pretty bad idea. This ticket should not be considered by itself. A data
 structure can easily be chosen once it is known exactly how it is going to
 be used.

 The data will mainly be used by plugins to determine whether or not a
 cookie should be set for a particular user or not.
 Pretty much any other code can also be executed or not (on a per-user
 basis), depending on whether the user has given permission for that
 category of use (e.g. marketing).
 The tickets have been split into smaller (perhaps hyper-focused) ones
 because this has resulted in more actionable input from the privacy team
 thus far.

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