[wp-trac] [WordPress Trac] #44043: Framework for logging/retrieving a users consent state

WordPress Trac noreply at wordpress.org
Tue May 22 10:50:09 UTC 2018


#44043: Framework for logging/retrieving a users consent state
------------------------------------+------------------------------
 Reporter:  cookiebot               |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Privacy                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  gdpr 2nd-opinion close  |     Focuses:
------------------------------------+------------------------------

Comment (by gisle):

 @xkon wrote:
 > @gisle nobody is going to force any new implementation on anyone. That's
 not how things are done and I'm sure you already know that.

 > So again it would be up to the user to 'use' any kind of plugin that
 accesses these functions to do whatever is needed to be done. If he
 doesn't want to well there's no change for him so @gisle that sorts your
 concerns about having extra 3rd parties etc. You don't have to if you
 don't like it, but the functionality has to be provided for whoever wants
 to use it as well.

 I am familiar with their [https://wordpress.org/plugins/cookiebot/
 (plugin)], and know fully well that even if we put the particular way of
 logging consent that is proposed in //this ticket// in core, //I// don't
 have to install their plugin. But then I need to find another method for
 keeping track of consent.

 I think that WordPress will //need// a consent logging mechanism in core
 to comply with GDPR. However, if the consent logging mechanism in core is
 done wrong, it will at least be a missed opportunity to do things right,

 For the sake of brevity, I will not any repeat the arguments I've already
 presented, but simply look at this proposed enhancement from a purely
 practical perspective.

 Cookiebot (the company) uses cookies for consent logging. In this ticket,
 somebody with the user name @cookiebot  propose that we use cookies for
 //all// types of consent logging that is required by the GDPR - not only
 for cookie consent.

 However, a cookie is a rather special type a personal data. Unlike all
 other types who data processed by a web-site, the controller does //not//
 control it. A cookie is always stored on the user's hard drive, and is at
 all times fully under the user's control. The controller can only access
 it and the information it contains as long as the user permits. The user
 can take away this access, simply by deleting the cookie (an operation
 that is supported by all browsers).  Cookies are also specific to a
 particular device. These days, users own and use multiple devices (desktop
 PC, laptop, pad, smartphone) so to secure consent from the user, you need
 to secure individual consent for each device, and the consent may not be
 consistent across devices.  This may be the recipe for a very confusing
 UX.  What do you do if a user has consented to you storing his email-
 address for the purpose of marketing on one device, but not on another?
 Do you poll all devices and let the majority decide, or can you pick the
 most permissive device? What happens if all the user's devices are offline
 when you want to sent out the newsletter. If data about what the user has
 consented to is stored in a cookie on the user's hard drive (which is
 offline), you have no way of knowing whether the user had consented or
 not.

 What happens if the user //delete// your cookie that tracks consent
 settings on all devices. Must this action be interpreted as withdrawal of
 consent, so you must immediately erase all the data the user previously
 consented to you having, or are you allowed to keep the data until the
 user is re-asked about consent (so you only erase on a opt-out)?

 For the record: I think WordPress should support consent logging in core.

 But perhaps not by using a cookie to store this log, which essentially is
 what this particular ticket proposes to do.

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


More information about the wp-trac mailing list