[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:                   |     Focuses:
-----------------------------+---------------------
Changes (by azaozz):

 * keywords:  close =>


Comment:

 Replying to [comment:14 carike]:
 > I believe that the implemented Consent API proposal
 (https://wordpress.org/plugins/wp-consent-api/) makes use of consent
 cookies and not of session storage. I don't think that there has been a
 specific discussion about this. I'll add it to points for Office Hours.
 > My instinct would be that a single session may be too short for the
 reasoning below.

 Yes, a single session is too short, but on the other hand it doesn't add
 yet another cookie for which the user has to give consent. It is
 guaranteed to be removed from the user's browser after the visit to the
 particular web site ends. I.e. the consent cookie by itself can be treated
 as a "breach of user privacy".

 The results can be seen currently (on non-WP websites) where if the user
 doesn't consent, each time they navigate to a new page on the same website
 they are asked to consent, again and again. This is super annoying :)

 If session storage was used instead, a "consent refusal" could be saved
 there and the site visitors won't be "bugged" with repeated consent
 requests.

 Of course, this is just another implementation detail, nothing more.

 > While there has pretty much been a strong consensus for quite some time
 now that a Consent API is necessary, we are still building consensus on
 what the implementation should look like.

 Right. For an API to be actually useful, it should be able to handle most
 of the needed work, and expose few functions/methods/filters to plugins
 that may want to use it. This generally means the API should be able to
 store, retrieve, and change consent settings for all groups of users. In
 addition it should (probably) provide UI for setting and changing these
 settings. This is particularly difficult as it means the "consent options
 dialog" for site visitors has to be on the front-end of the website, and
 "work well" with all themes. Not sure if the current plugin does that
 (yet).

 > The original implementation does not distinguish between registered
 users and website visitors.
 > A Slack discussion had this outcome on P2:
 https://make.wordpress.org/core/2020/08/22/request-for-input-consent-
 preferences-for-logged-in-users-consent-api/
 >
 > This is why I believe that tickets like this one are necessary.
 > We have some very specific design questions that we need to answer.
 > ...
 > So far, the conclusion of the various discussions have been that logged
 in users should be treated differently logged out users, because if you
 are a person who regularly deletes your cookies, seeing a pop-up banner
 every time you visit a site even though you are logged in isn't the best
 user-experience and contributes to notice-fatigue.

 That's another good point. Thinking that there is a pretty big difference
 between logged-in users and site visitors. For starters the "consent
 options dialog" for visitors has to be on the front-end, and save the data
 in the visitor's browser. Implementation-wise it can either be fully js
 based or an iframe.

 For logged-in users the consent options would probably be more granular or
 extended as a lot more "happens" in wp-admin, and the options should be
 saved in user_meta in the DB. That will make them accessible every time
 and from every device, different browsers, phones, etc. Best place for
 them would be the User Profile screen. That screen can easily be extended
 to include everything necessary and "feel" an integral part of WP.

 > However, registered users should be re-prompted for consent if there are
 changes to the consent that is being asked for (and a hook makes sense so
 that plugins can prompt again if they would like this to happen at any
 particular point).

 Right. The current UI way of doing that is by showing a "bubble" on the
 top menu item. Can eventually also show a notice, but lets leave that for
 the designers.

 > While there have been answers to some of these questions, based on past
 experience, I expect that the last 3 will only receive significant input
 once there is a proposed implementation.
 >
 > This ticket also asks design questions. In particular the following:
 >
 > {{{
 > 1. Should plugins be able to add extra consent types?
 > 2. If plugins should be able to add additional consent types,
 > should these be "top-level" consent types, or should they be nested,
 > or should they be both?
 > }}}
 >
 > Paapst's comment above shows that there are different opinions about
 this in the Privacy Team.
 >
 > There are many of these types of implementation questions and the only
 way that they have gotten resolved thus far is by creating simple examples
 of what the implementation might look like.

 Perhaps it may be good to gather a number of examples of how (site
 visitor) consent options are handled on other sites. Currently this is
 generally something that is being shown only to visitors from the EU, so
 the people collecting that data will have to be based there.

 Would be really good to "investigate" how other popular website building
 software handles this.

 > While I hear your argument and respect your view that all of these
 issues should be handled under #51110, history has shown that doesn't
 work. Because as soon as we try to discuss too many implementation
 questions in a single go, the discussion devolves into something no one
 can follow and we scare off the multi-disciplinary contributors we need in
 order to get this done.

 The idea was to "gather" all the requirements there, and then see what's
 technologically possible and what implementation makes sense. Then "hand
 off" to the designers for the actual UI.

 I agree, it is quite a bit of work to try to translate the legal
 requirements into "actionable items", but this is (perhaps) the most
 important step in implementing this feature. Perhaps we can reach out for
 some help :)

 For example, if the consent options have to comply only with GDPR, the
 requirements can be taken from https://gdpr.eu/gdpr-consent-requirements/.
 (Note that this site is build with WP. If we implement the consent options
 dialog on the front-end, it will (probably) be shown there too.) :)

 > No. The Consent API would apply to someone who runs a blog and who wants
 to place any personalized ad as well, even if they do not allow account-
 creation on their site.

 Right. What I meant was that handling of consent options for site visitors
 would (likely) be quite different from logged-in users. One would likely
 be js, the other php, etc.

 > We already have one iteration for the Consent API.
 > ...
 > Rogier and others have wanted to move the code over to the WordPress
 repository, but that has not happened yet, so the fact that it lives in a
 private repo is also a challenge.

 I can help there, but thinking the current implementation is not quite
 ready yet. The API should be able to do most of the work, have UI, etc. Of
 course, this will be added after the above questions are cleared/decided.

 Removing the "close" keyword as there is quite a bit of discussion here,
 but still thinking this ticket is a "follow-up" and can be decided only
 after the implementation requirements are set.

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