Opened 7 years ago
Last modified 4 years ago
#44043 new enhancement
Framework for logging/retrieving a users consent state
Reported by: | cookiebot | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Privacy | Keywords: | 2nd-opinion privacy-roadmap feature-plugin |
Focuses: | javascript | Cc: |
Description
When a users visits a website for the first time, the user should be able to opt in or out from cookies. There are a couple of WP plugins that provide such functionality. The most common cookie categories are; necessary, preference, statistics, marketing. Other plugins should be able to retrieve the users consent state through WP Core, which allows them to avoid putting unwanted cookies in the users browser, without having to explicitly support certain cookie consent plugins.
Change History (48)
This ticket was mentioned in Slack in #gdpr-compliance by cookiebot. View the logs.
7 years ago
#2
@
7 years ago
- Keywords needs-patch gdpr 2nd-opinion added
- Severity changed from major to normal
- Version changed from 4.6.1 to trunk
#3
@
7 years ago
Hi 👋 @cookiebot and welcome to trac!
Just fyi we already have a discussion started about logging in general ( that includes consents as well and there's already a basic proposal for an ongoing class that plugins/core will be able to use to see if a consent was given ) see #43797 .
Since we're in RC at the moment this will be discussed for a future relase though as there are some tricky parts behind keeping 'consents' that need a good deal of thinking before proceeding.
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
7 years ago
#5
@
7 years ago
Thanks @xkon
Had a read at #43797 and you've got a good discussion about what to log and how to log it.
To start this ticket out, id like to explain how Cookiebot works.
Cookiebot stores a cookie which contains the users consent state (and what may be referred to as the consent id, which can be used as a proof). Storing a cookie to tell whether or not a user wants cookies may sound paradoxical, however to make something that could become a long discussion short, it is fully allowed and considered a necessary cookie.
What would be great is if we could signal the consent state to WP Core, so that other plugins can use the information to render their cookie setting tags accordingly (script, img, iframe, etc), accordingly. The signal could, for instance, last for the whole session, so that it would not be necessary to store the consent state in the WP database.
However, if the website owner wants to save the consent state in WP, that would also be possible. There is one challenge though.
In #43797 you mention a consent id, but I am not sure how it is generated. As mentioned earlier, we generate our own id. Would it be possible to send our id directly to WP core, and maybe somehow have it mapped with the wp-generated consent id, that is used for everything else user-gdpr-related ?
#6
@
7 years ago
- Keywords close added; needs-patch removed
Thinking that if we are going to do logging, all of it should be in one place. This sounds like a duplicate of #43797.
#7
@
7 years ago
@azaozz saw in #gdpr-compliance that there was another request for merging the two tickets, however @xkon replied to keep this one for the cookies part, maybe for separation of concerns.
#8
@
7 years ago
Another thing came to mind.
When a user enters the website for the first time, the whole site including all plugins that render output (possibly cookies and other trackers) are executed.
The following requirements in the General Data Protection Regulation (GDPR) and the ePrivacy Directive (ePR) haveto be implemented:
- Prior consent on other than strictly necessary cookies (ePR)
- Prior consent on personal data (GDPR)
How could plugins re-render script tags that e.g. set marketing cookies after consent to these has been given, without having to reload the entire page ?
Currently the way Cookiebot works is to withhold any script from execution, by changing type="text/script" to type="text/plain". If the user gives consent to the e.g. marketing cookies then the scripts are executed, without a page reload.
#9
@
7 years ago
Currently the way Cookiebot works is to withhold any script from execution, by changing type="text/script" to type="text/plain".
Uh, so basically the sites run as if js is disabled in the browser unless the users "want" marketing cookies? How many users will want to get marketing cookies? I think ~0
. Not sure how well that would work...
#10
@
7 years ago
@azaozz Oups, what I meant with "any script" was any script that the user has marked as being a cookie setting script. We use an attribute to mark it. A script tag can be marked with one or several labels, depending on the kind of cookies it is setting (preference, statistics, marketing).
#11
@
7 years ago
Aahhh, I see, much better :)
I'd still be a bit "wary" about the number of users that would agree to "marketing cookies". If the blocked scripts do some other things apart from setting the cookies, that may limit the site's functionality quite a bit.
At the same time I think that GDPR and friends will finally manage to kill cookies usage completely, which is a shame. There are many many ways to track users that cannot be controlled as easily as cookies (anybody can delete their browser cookies at will). Killing cookies is pretty much "lost functionality for websites with no improvement for user privacy". But that's another discussion :)
#12
@
7 years ago
@azaozz Spot on!
Blocking the whole script may limit the sites functionality.
That is exactly why we need a framework for signaling the consent state.
If the script is being assembled in PHP, the plugin developer could construct the script so that it works, even if tracking is not wanted. Cookiebot does provide a JS API to get the consent state, however the whole point is to make a plugin-agnostic framework.
You're right, tracking may come in other forms than cookies, such as HTML5 Local Storage, Flash Local Shared Object, Silverlight Isolated Storage, IndexedDB, ultrasound beacons (yes, some use ultrasound for tracking), pixel tags etc.
This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.
7 years ago
#15
@
7 years ago
- Type changed from feature request to defect (bug)
This ticked seems to confuse granular consent (as required by the GDPR) and cookie compliance (as required by Directive 2002/58/EC, aka. "the cookie directive"). I think they need to be kept separate.
A cookie is a rather special type a personal data, because you do not store it or control it. The cookie is always stored on the user's hard drive, and is at all times fully under the user's control. You can only access it and the information it contains as long as the user let you. If the user wants to withdraw consent to you having access to this data, the user deletes the cookie. End of story. This is why cookie compliance need to be treated different from consent to process personal data where you (or a third party acting as a processor for you) control access to the data.
I simply do not see the need for using an external service (such CopyBot) to handle my users' cookies, or to handle these permissions myself. What is proposed here is to take some data where the user is fully in control, and turn into something where the user is only partial in control. As a controller who cares for my users' privacy, I think this is a horrible idea.
#16
follow-up:
↓ 18
@
7 years ago
Hi @gisle,
The GDPR requires prior consent for cookies used for marketing purposes. These could be 3rd party cookies stored by YouTube, Facebook Pixels, etc. 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.
I simply do not see the need for using an external service (such CopyBot) to handle my users' cookies, or to handle these permissions myself. What is proposed here is to take some data where the user is fully in control, and turn into something where the user is only partial in control. As a controller who cares for my users' privacy, I think this is a horrible idea.
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.
#18
in reply to:
↑ 16
@
7 years ago
Replying to 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 if it will remain set after the session - and in that case, also 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 going to 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 of 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.
#19
@
7 years ago
@gisle
First of all, I think this discussion is way off track. It has nothing to do with the proposal of the ticket, and probably you haven't understood what we want with this ticket either. If you want to discuss the GDPR, then maybe we could move the discussion somewhere else? E.g. #gdpr-compliance.
What you are proposing is to deviate from what has been legal, and considered best practices, for the last 16 years...
Again, this clearly shows that you haven't understood our proposal at all.
You're promoting a different plugin while you're bashing ours, without bringing any concrete arguments, just your misunderstood view of what we want here. Just so that you know, we have had a number of lawyers evaluate Cookiebot- for example DG Connect under the European Commission, The Danish Business Authority, Google, Oracle and a number of large enterprise customers in France, USA, Germany, UK and Denmark as well as two independent lawyers in Denmark. Google also recommends Cookiebot to its advertising partners: https://www.cookiechoices.org.
However, this has nothing to do with Cookiebot.
As a reaction to many users frustrations over their plugins not being GDPR compliant, we are trying to discuss a feature where plugins could get a user's consent state without having to rely on some other third-party plugins. @xkon @allendav @chirscct7 @azaozz care to comment?
#20
@
7 years ago
No, I don't want to discuss the GDPR.
However, I want to discuss whether the "enhancement" you propose to introduce to WordPress is 1) desireable and 2) needed (in order to comply with the GDPR).
I think those are legitimate concerns when an specific new feature is proposed.
Currently, I think is undesirable because it increases complexity and would introduce yet another third party into my infrastructure.
A also think it is unneeded because better solutions already exists (better = simple to use and does not require trusting a third party).
#21
@
7 years ago
However, I want to discuss whether the "enhancement" you propose to introduce to WordPress is 1) desireable and 2) needed (in order to comply with the GDPR).
I think those are legitimate concerns when an specific new feature is proposed.
I couldn't agree more.
Currently, I think this feature is undesirable because it increases complexity and would introduce yet another third party into my infrastructure.
The description of the ticket may be implicit, so i'll try to describe it some more.
First of all, in order for all of this to make sense, we would have to agree on one thing; with the new GDPR rules, website visitors must give prior consent to specific types of cookies, such as online trackers for marketing purposes. Do you agree with this @gisle, and are we on the same note in regards to what prior consent is? Prior consent means holding back e.g. marketing cookies, until the user has opted-in to them.
Now, take a Wordpress website that has 5 different plugins which each render stuff that sets marketing cookies on the front page. Moreover, let's say that the tags that are rendered, are outputted/assembled through PHP. How do you suppose these 5 plugins should obtain the users consent for marketing cookies? Should they each come with some kind of pop-up asking for consent?
#22
@
7 years ago
@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.
There was a discussion in a different ticket about Logging the consents etc so there was the need to create extra ones for a different 'scope' but on a similar matter.
The idea is to see if we could create in core the functionality needed for plugins to check for any given consent and then act accordingly on loading or avoiding to load scripts etc.
If we go forth with a consent logging mechanism ( and we probably will as it's needed ) there's no point of not doing an all around class that could take care of everything imho.
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.
Now the only 'issue' let's say I see with this theory from the OP and I'm not sure I'm 100% with is this Other plugins should be able to retrieve the users consent state
I don't like giving access to all plugins on everything. As this could be easily exploited by some not so 'trusty' ones.
It's the same principle as in logging we have to find a way that the consents are handle individually if possible or there's only 1 access somehow if that makes sense?
For example if I say 'yes' to a 'marketing' cookie I wouldn't want that to be misused by another plugin and add 10 things more because I said yes to 1 ( if that makes sense ).
#23
@
7 years ago
@cookiebot wrote:
First of all, in order for all of this to make sense, we would have to agree on one thing; with the new GDPR rules,
My disagreement starts here. There are no new GDPR rules about cookies. After the GDPR becomes law, the use of cookies will still be regulated by Directive 2002/58/EC (which, unlike directive 95/46/EC, will not been revoked when the GDPR becomes law).
For the record: GDPR only mentions cookies once (Recital 30). There are no "rules" (new or old) about cookies in the GDPR.
(There are new rules about some other things in the GDPR. These new rules should not [and IMHO cannot] be dealt with by using cookies.)
website visitors must give prior consent
You seem to think that "prior concent" applies to cookies. This is also wrong. Please re-read Directive 95/46/EC (Recital 25). It says:
Users should have the opportunity to refuse to have a cookie or similar device stored on their terminal equipment
"Opportunity to refuse" is *not* the same as "prior consent".
to specific types of cookies, such as online trackers for marketing purposes.
I am also unable to locate any specific requirement for "online trackers for marketing purposes" in any reputable legal literature I have reviewed. Where does this specific requirement come from?
However, I've noticed that you frequently refer to various categories of cookies ("necessary, preference, statistics, marketing"). I know the legal basis and definition of the "necessary" category (i.e. its legal basis is Directive 95/46/EC Article 5(3)) But where does the rest of these strange categories come from?
Do you agree with this @gisle,
No. I am really sorry. It just seems I am unable to agree to a single thing that you say.
I have tried hard to see if the "Cookiebot-approach" to consent produces any advantage or functionality that someone who controls a web site should want or could use - and I just don't see it. Again: Sorry.
I understand from a comment 19 that your plugin is very popular and is used by many companies, including some very large enterprises. I am happy for you! However, I always evaluate software solutions independent of their popularity.
#24
@
7 years ago
@gisle afaic the ePD was going to be updated as well in 25 along with GDPR but it is unlikely to happen, so we can't know for sure their new ways of dealing with cookies especially ( I might be totally wrong but that's what I know from lawyers and non-lawyers on this matter).
Apart from that though as seen reading the LB for processing ( https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/ ) and as seen in http://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=623051
Quote from the europa.eu document -> Page 17:
In any event, consent must always be obtained before the controller starts processing personal data for which consent is needed. WP29 has consistently held in previous opinions that consent should be given prior to the processing activity.44 Although the GDPR does not literally prescribe in Article 4(11) that consent must be given prior to the processing activity, this is clearly implied. The heading of Article 6(1) and the wording “has given” in Article 6(1)(a) support this interpretation. It follows logically from Article 6 and Recital 40 that a valid lawful basis must be present before starting a data processing. Therefore, consent should be given prior to the processing activity. In principle, it can be sufficient to ask for a data subject’s consent once. However, controllers do need to obtain a new and specific consent if purposes for data processing change after consent was obtained or if an additional purpose is envisaged.
I think it's clear that you do need consent first and then start processing the data ( not always of course as it depends on the situation ).
One extra example I can give from the coding world is Google AMP project as it's adding a consent component similar to the discussion that you could basically put let's say for example the analytics scripts 'on hold' until the user gives his consent to track him.
Now if we take into account that pretty much everybody is using analytics which in it's own way is tied to re-marketing and anything else that Google adds behind the scenes. A consent is pretty much mandatory and should be used pretty much everywhere beforehand the way I see it.
#25
@
7 years ago
@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 (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.
#26
@
7 years ago
I'm personally not that much interested in the 'cookies' themselves as I'm totally with you on the matter that it is on the user side so he's in full control. I'm interested in putting on hold any unwanted data processing before the user has given consent (again depending the situation) and logging that consent.
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.
For the sake of good discussion and alternative solutions we splited this up from #43797 so we can later see any 'hidden' differences or advantages/disadvantages that might come up and fully decide how to proceed on building this into core.
Let's not forget that there are 2 different things that we need to tackle here in general:
1] The actual consent logging. This is to provide a way for the website owners to have sufficient proof if needed.
2] A consent 'state'. This is so the users are not spamed all the time with the same consents if possible.
Maybe somehow we could use 'both' tactics at the end or split them up completely as they are for different needs.
---
Also thank you for taking the time to write up detailed replies with insights as well as it's really helpful.
#27
@
7 years ago
@gisle
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.
Again I believe that you've misunderstood our proposal. We do not propose that WP uses a cookie for all types of consent logging that is required by the GDPR. We're only interested in online tracking. We ourselves do use a cookie to store the users consent on the users device. We also store it in our backend system, so that the website owner can later use it as proof.
We are simply informing you how we do things, which you can then consider, and you're welcome to use this information however you like. Is this not valuable information?
What we are proposing, is a framework that can be used to set and retrieve the consent state. That's all. How this is implemented is entirely up to those that are going to implement it.
I am also happy that we've went from discussing whether or not cookies should be handled in the GDPR, to a technical discussion.
This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.
7 years ago
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
7 years ago
This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.
7 years ago
#33
@
7 years ago
I'm using a custom table in https://wordpress.org/plugins/avatar-privacy/ to track consent for anonymous content authors and user meta for registered users (consent for transmitting their hashed mail address to Gravatar.com to retrieve a profile image). Both methods do not leave an audit trail at the moment, but only store the most recent change. Having a generic framework for consent logging in Core would be beneficial.
#34
@
7 years ago
@xkon
Now the only 'issue' let's say I see with this theory from the OP and I'm not sure I'm 100% with is this Other plugins should be able to retrieve the users consent state I don't like giving access to all plugins on everything. As this could be easily exploited by some not so 'trusty' ones.
It's the same principle as in logging we have to find a way that the consents are handle individually if possible or there's only 1 access somehow if that makes sense?
For example if I say 'yes' to a 'marketing' cookie I wouldn't want that to be misused by another plugin and add 10 things more because I said yes to 1 ( if that makes sense ).
When someone gives consent to marketing through Cookiebot, they are giving consent to a "purpose". The purpose could be; online tracking for marketing purposes. They are not giving consent to individual cookies. If consent for marketing has been given, then plugins should be allowed to set marketing cookies or trackers.
It would not be particularly user friendly or efficient to give consent for each individual cookie, say if there are 500 of them on a site.
#37
@
6 years ago
- Keywords gdpr removed
Removing the GDPR keyword. This has been replaced by the new Privacy component and privacy focuses in Trac.
This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.
6 years ago
#40
@
5 years ago
- Keywords changed from 2nd-opinion, privacy-roadmap to 2nd-opinion privacy-roadmap
As developer of Complianz GDPR I would welcome this enhancement: a core API where cookie plugins can set the current consent level, and plugins can retrieve the consent level. Because there can be discussion about the needed categories, and in combination with for example Tag Manager there can be custom categories, I think there would have to be only three base categories, functional, statistics, marketing, which can be extended with a filter.
Because it's not possible to prevent other plugins from placing marketing cookies using PHP, this feature could improve compliancy on sites. Additionally, if a plugin places tracking cookies in a javascript file that also performs other functions, the only way to block this cookie currently is to block the entire script, which might break things. If a plugin can check for the WP core consent status, this would be great.
Because the GDPR requires the user to explicitly consent to placement of marketing cookies, and depending on the setup, statistical cookies, there's no question about the usefulness of such a feature in my opinion.
This ticket was mentioned in Slack in #core-privacy by cookiebot. View the logs.
5 years ago
This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.
5 years ago
#43
@
5 years ago
- Focuses javascript added
- Keywords feature-plugin added
- Milestone changed from Awaiting Review to Future Release
An update on the Consent API;
Thanks to @RogierLankhorst & all participating contributors the WP Consent API plugin was released to WP.org for initial alpha testing.
Plugin Page - https://wordpress.org/plugins/wp-consent-api/
Github Page - https://github.com/rlankhorst/wp-consent-level-api
Testing, Feedback, Issues, PRs, etc are all welcome.
Continued progress and collaboration on the project will be facilitated through the repository and in #core-privacy on WP.org Slack.
I've left the component as 'General' because I'm not sure where this exactly fits in.
See the conversation in #gdpr-compliance.