[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