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

[WordPress Trac]

#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):

 Replying to [comment:16 cookiebot]:
 > The GDPR requires prior consent for cookies used for marketing purposes.
 […] Moreover, if cookies are set for statistical purposes, and the users
 IP address (which is considered personal data under the GDPR) is stored by
 the 1st or 3rd party, consent is required as well.

 The above is quite inaccurate (it probably originates from reading some
 blogs about the privacy legal framework of the EU, not from professional
 legal advice). For one thing the obligations of the controller regarding
 cookies cannot be found in the GDPR, they are laid out in Directive
 2002/58/EC (aka. "the cookie directive") which is 16 years old this year.
 Also, the notion of an IP address being personal data does not comes from
 the GDPR, it follows from case law from the ECJ (several cases, but most
 notable C‑70/10 (28 January 2010) and C-582/14 (19 October 2016). The GDPR
 only mentions cookies once, in Recital 30, and it provides absolutely ''no
 guidance'' about implementation. So to understand what is required, you
 need to examine the original sources.

 But, yes - hard consent is required for some purposes of processing (more
 purposes than the two you mention, btw.).

 > I am not sure if we are talking about the same thing here. We are not
 taking any data for the user, and we consider this proposal to be an
 enhancement to WP, rather than a defect.

 For 16 years, the best practice for the controller has been to first
 perform a cookie audit, and then set up a plugin to inform the user about
 what cookies are set, for what purpose, by what site (i.e. to make it
 clear what is first and third party cookies), and whether it is a session
 cookie or a if will remain after the session - and in that case, its
 duration). The usual method to inform the user is to show a popup with a
 link to the required information when the visitor first visits the site,
 and keep showing this popup until the user clicks "OK" to indicate
 consent. A lot of these plugins exists, but "Cookie Consent" by
 ''Catapult_Themes'' seem to do everything that is required by the GDPR.
 (There are probably lots of others that do the job equally well.)

 Because cookies are stored on the ''user's'' hard disk, under the full
 control of the user, withdrawing consent as required by the GDPR can and
 should be done by the user himself, simply by deleting the cookie.
 Cookies can be deleted one by one, or in bulk, giving the user the
 granular control over cookie consent that is required by the GDPR.

 What you are proposing is to deviate from what has been legal, and
 considered best practices, for the last 16 years. You say that the new
 practice you want to introduce is an "enhancement", not a "bug".  I am not
 get into a type tagging war, but in my eyes, ''CookieBot'' just adds
 another unneeded third party service that could potentially track my users
 in the computer systems where I am the controller.  Since it does not do
 anything ''better'' than current best practices, I simply see no need for
 it, and I suspect that installing ''CookieBot'' would break the GDPR
 compliance with my site unless I am able to negotiate a Data Processor
 Agreement (me as controller, ''CookieBot'' as processor) that provides me
 with the controls and assurances I am, by law, required to have as a
 controller.  As I see no utility for myself or my users for this service,
 negotiating such a DPA would of course be a waste of time.

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