[Feature] Consent Management Recipe

I would suggest to give the COOKiES → module a try:

• it has many integrations with popular other modules
• can handle even markup in output filters (e.g embedded iframes in user markup)
• handles JS output of other modules
• provides a nice ui through the COOKiES JSR library

Some thoughts:

• I agree with giving the cookies → module a try. As mentioned, we're currently using EUCC and are not very happy with it. If anyone has experience with getting compliant implementations using the cookies module, do share any caveats or limitations you experienced
• Including Cookie Content Blocker → or a similar module will be required.
• We currently use some extra modules to do things like adding datalayer events, extending the consent modal and providing ways to add consent based videos etc. I assume we would prefer to make a decision on which modules to use and then try to update these modules to include what we need rather than making an extension module?
• We might want to do a little bit of research as to what is being used most for implementing tracking scripts etc. so we know what to support. E.g. Google Tag Manager, Matomo, ...

Like the discussion points a lot. Wanted to add a proven practice from Murray Woodman from Morpht, he told me about. They are using a widget from https://github.com/orestbida/cookieconsent and are very satisfied. It's not yet tightly integrated into Drupal, but that could be done.

They have a demo site at https://govflix.convivial.io/ with a link to privacy settings in the footer, which uses that widget. Note: if you're using uBlock Origin, that widget gets blocked. To test this out, you need to disable uBo for that domain.

try to update these modules to include what we need rather than making an extension module?

I'd say that's completely open, and we may even come to the conclusion that building a new module, which takes on the best parts from all the existing ones, is the better way forward. With time constraints in mind, using something that exists, is the preference. But we need something that meets our needs.

I put together a doc, which could be a basis to see which consent "popup" tool fulfil European laws.
Nearly finished it. will crosslink it here then. just a note, that I am working on that.

in todays meeting we've agreed on starting to collect all modules that are related to gdpr, ccpa, privacy and alike and to iterate on the list in this issue. it isnt in any way complete nor perfect but as a starting point, here are a few matches that meet the criteria completely or at least in part (i've searched for the aforementioned keywords on https://www.drupal.org/project/project_module → )

Drupal 11
https://www.drupal.org/project/assetfetcher →
https://www.drupal.org/project/clickioconsent →
https://www.drupal.org/project/cmp_sirdata →
https://www.drupal.org/project/content_reporting →
https://www.drupal.org/project/cookie_consent_notice_by_cookieyes →
https://www.drupal.org/project/cookiebot →
https://www.drupal.org/project/cookieinformation →
https://www.drupal.org/project/cookiepro →
https://www.drupal.org/project/cookiepro_plus →
https://www.drupal.org/project/cookies →
https://www.drupal.org/project/cryptolog →
https://www.drupal.org/project/eu_cookie_compliance →
https://www.drupal.org/project/eu_cookie_compliance_matomo →
https://www.drupal.org/project/fz152 →
https://www.drupal.org/project/gdpr →
https://www.drupal.org/project/gdpr_alert →
https://www.drupal.org/project/gdpr_compliance →
https://www.drupal.org/project/ip_anon →
https://www.drupal.org/project/klaro →
https://www.drupal.org/project/mytube →
https://www.drupal.org/project/noreferrer →
https://www.drupal.org/project/piwik_noscript →
https://www.drupal.org/project/uniconsent →

Drupal 10
https://www.drupal.org/project/ad_entity →
https://www.drupal.org/project/adsense_consent →
https://www.drupal.org/project/civicccookiecontrol →
https://www.drupal.org/project/consent_manager →
https://www.drupal.org/project/cookie_content_blocker →
https://www.drupal.org/project/cookies_module_handler →
https://www.drupal.org/project/entity_legal →
https://www.drupal.org/project/eu_cookie_compliance_gtm →
https://www.drupal.org/project/gdpr_onetrust →
https://www.drupal.org/project/google_analytics_cookieless →
https://www.drupal.org/project/html_tag_usage → (the second point in the potential use case section)
https://www.drupal.org/project/iubenda_integration →
https://www.drupal.org/project/legalweb_cloud →
https://www.drupal.org/project/smart_ip → (able to recognize “gdpr countries”)
https://www.drupal.org/project/social_login →
https://www.drupal.org/project/tracking_options →
https://www.drupal.org/project/youtube_cookies →

Wow, I had no clue that there are so many gdpr related modules.

My first thought about this: while its imo totally OK to use third party libraries like CookieConsent or Klaro (or whatever instead of doing that work agein) as a consent management tool, I would rather rule out modules that use third party services (like Cookiebot or Clickio) as they would establish dependencies to external systems.

External libraries should be installed/hosted locally anyway and where that is not possible for whatever reason, the assetfetcher module sounds promising (but I don't have any experience with it - has anyone used it?)

100% agree that we should not rely on 3rd party service like CookieBot, because, among other things, they continuosly tend to restrict the terms of usage or free usage limits, so we could get trapped easily.

I have not used it personally, but have also heard some good words about https://github.com/orestbida/cookieconsent . Though not sure if it does have similar features like the eu_cookie_compliance module (like removing disallowed cookies by default, and similar).

I've collected all information from the comments in here and structured them in a spreadsheet. There are 48 modules listed and when applying certain filters like no external services and D11 support, there are just 16 left. From those, there seem to be 3 (marked green in column A) that we should analyze in more detail.

The columns K-Q mention some features to indicate which module supports which. This is certainly not complete, if anyone has something to add, feel free to do so as the link above grants edit access.

if it is ok i would move the "russia" column out of the orange colored group and into a new to be created one and add two additional columns to that newly created group, gdpr and ccpa... that way it could be illustrated if a module is "specific" about/for a particular regulation.

Following the excel sheet linked in the IS, there are 3 main modules that we need to test in all detail to determine which one, or combination of modules, should go into our recipe.

The Cookies module is our favourite, but it depends on the CookiesJSR library where we have trouble to get in touch with its maintainer.

The GDPR module is probably not so well maintained, but it comes with important features for the field API to declare sensitive data fields.

And the EU Cookie Compliance module has the most users and a lot of features, but is due for a rewrite.

As far as I can see the GDPR module does not provide a cookie consent feature itself. According to its README.md the "Checklist for site admin (recommend modules like cookie consent".

Neither COOKiES nor EU Cookie Compliance seem to work without javascript. Javascript may be disabled in some company web browsers and is usually not available in text-mode web browsers. Nevertheless a cookie is set when accessing e.g. google.com with elinks without asking for consent. However, according to jurisdiction, having enabled cookies in the browser does not permit the assumption of consent, because cookies are usually allowed by default, which is the case with elinks.

*copied over from the slack channel. i've initially thought to discuss things there and post these findings in dedicated issues in the contrib module isse queues):

i’ve tested and compared the cookies and the eu cookie compliance module last night with a focus on ux and a11y. in regards of the cookies module there are a few more downsides alongside the outstanding license issue for the cookiejsr library.
if you are trying to install all submodules that ship with the cookie module you will run into a few issues. two required dependencies have no drupal 11 version yet. and if you are trying to install the filter module (which is beta) you will run into error messages requiring you to manually composer require symfony components. first a single component is required (css-selector) . after you fixed that and required and you try to install the module you get another error requiring another symfony component dom-crawler) but even though you composer require it it will still be labeled as missing and an error is showing on subsequent tries to install the filter module. that experience is suboptimal. same the other way around if you try to uninstall all modules you installed at one point in the context of the cookies module. in particular if you havent installed it yourself or the install is too far in the past and you cant remember. it is a scavenger hunt.
another downside setting up the module (something that wouldnt be an issue with a recipe) is the fact that after requiring the modules you need to add a cookies block on the block layout page. something that could be easily missed if you not closely read the project page.
comparing to the feature set of the eu cookie compliance module i also wonder if the cookies module also minds and respects the do not track setting of the browser. the eu cookie settings module has an explicit setting for that, in the cookies module i was unable to find that. the eu cookie compliance module also has the ability and option to only show the cookie banner to visitors from the EU in case you are meeting the following constraint “you need to install the smart_ip module or install the geoip module or enable the geoip_country_code_by_name() PHP function.”
another downside is the cookie module has a single menu item in the admin menu. if you click the link you get to admin/config/system/cookies which is an overview page with four links (coookies configuration, widget texts, groups, services) if you click one of the links you get to a page with four primary tabs with the very same links. so that overview page is obsolete and requires just an additional click
i really like the level of granularity you are able to adjust the consent. in particular the way you are able to create groups and then assign services to the different groups. that is solved way more elegantly than with the eu cookie compliance module. there you only set up the groups but what is within those groups is not that straight forward and i havent figured that out last night. and it is also really nice being able to adjust all the microcopy in context of the dialog modal for the cookies module.
and the last group of issues is the fact that the project description promises full accessibility, but on a brief look some focus outlines were missing and for screenreader users it might be challenging to spot the dialog modal depending how they explore the page. if the look for buttons the would spot the deny all,accept all and cookie settings button. screenreader users are not necessary inclined searching the surrounding context of an element. and the exploration on new pages usually relies on either tabbing, going through the headings and or links. due to the fact the the modal has no heading the cookie documentation link might be the sole point of entry and clue there. ideally a dialog element would be used. the cookies module isnt using that for the main dialog modal. they are only adding an aria-modal for the cookie settings modal. but it would be way more important for the main modal tbh. to get an idea about the problem space leonie watson is outlining the problems of cookie consents for screenreader users. leonie is blind, a screenreader user, and she is on the w3c advisory board as well as co chair of one or two w3c working groups: https://www.youtube.com/watch?v=Uaqo4FOI_DY
so overall the module would require “some” additional work. due to the fact that anybody and grevil dont have any capacities in the next 12 months i would consider that problematic combined with the licensing issue. but in general i consider it still ahead and the more solid and flexible solution compared to the eu cookie compliance module.

in regards of the eu cookie compliance module, it has the same problem like the cookies module, it has a single menu item that leads to an overview page which is an intermediate step to the actual page with the primary tabs. and the most confusing part is the grouping / category feature. you are able to create a group and set a default checkbox state for that group but what goes into that group is not clear at all. and there is no clear path forwards in the ui for that.
and the rest of the settings is packed into one single page with a lot of descriptions and help text which is sort of overwhelming.
from an accessibility perspective, the dialog modal is styled in a vein with olivero which is good but the focus outline isnt meeting sc1.4.11. … the more link in the dialog modal is leading into nowhere aka back to the same page. out of the box there seems to be no “more info” information to display but also it is not apparent where that more info is set to provide it to the user. and the dialog modal has the same problem as the cookies module it is not using the dialog element nor the aria-modal attribute.
and it has also be noted that the available version is 8.x-1.25 but it is noted in the project description that there is work on version 2.x
so overall the eu cookie compliance module looks like the more basic option compared to the cookies module. both modules definitely require additional work. personally i would still prefer the cookies module if the licensing could be negotiated with the maintainer. cookies looks like the more solid starting point never the less despite its numerous listed downsides / flaws.

in regards of the gdpr module. it looks like it does not include cookie consent feature. the main feature is around a gdpr checklist that sort of implies that by checking all checkboxes (some require manual tasks) will make your site GDPR compliant. wording wise i consider that problematic. you cant guarantee that. not sure if a simple rewording would do the trick. another downside wording and scope wise is it is only targeting gdpr. overall the feature set looks like similar or close to the same what we are trying to accomplish with the dppca module.
but it feels not very intuitive on any other page than the checklist one and there are quite a few more settings pages. the legal implications as well as the technical implications are not very clear on most of the settings pages. might be eased with a preconfigured recipe to see how things are set up and what consequences those settings have but still hard to grok.

but that brings me to my biggest concern. if you install all the modules in the general data protection regulation group on the /admin/extend you already notice that several additional dependencies that got installed but that are not contained within that group are installed alongside.

if you try to uninstall that module at a later point and you try to remove everything that got added by the gdpr module things will turn into a scavenger hunt. to find all those modules outside the general data protection regulation group is tricky plus on the uninstall page you dont have that grouping. AND it is also impossible to uninstall one of the gdpr modules because a field is in place. but that field was not added on a content type. so you have to got to /admin/reports/fields then go to admin/config/gdpr/tasks/types/gdpr_remove/edit/fields and then remove the field there. then you can finally proceed uninstalling the rest of the modules mostly stepwise. a pretty tiring experience. so imagining the gdpr module would be picked for the privacy recipe and at a later point the gdpr module would be replaced with the dppca module i imagining that uninstall step tricky. and is it possible to actually “uninstall” something with a recipe at all with an included migration? i think that move from gdpr to dppca at one point have to be kept in mind for the evaluation process.

I've also tested a few modules for the last couple of days. Before summarizing my results, let me comment on a few statements above:

Neither COOKiES nor EU Cookie Compliance seem to work without javascript.

@boromino yes, as far as I can tell, that's what all sites are doing. Haven't seen any non-javascript solution anywhere yet. I guess, we could live with that.

Nevertheless a cookie is set when accessing e.g. google.com with elinks without asking for consent.

@boromino what are elinks? I don't remember if I ever saw them. Is this about embedding external content? Then, this could be handled with cookie_content_blocker

in regards of the cookies module ... install all submodules that ship with the cookie module you will run into a few issues

@rkoller, I think all those issue could be resolved with a proper recipe. Same goes for the block that needs to be placed. The uninstall issues are probably less of a concern for our current project. But the external library seems to be such a big issue, that we have to rule out the cookies module for now.

in regards of the eu cookie compliance module ... there is no clear path forwards in the ui for that.

@rkoller, for Drupal CMS we should aim for a non-configuration approach for the users as an ootb solution. So, we shouldn't worry about that too much, if we manage to prepare reasonable default config.

so overall the eu cookie compliance module looks like the more basic option compared to the cookies module. both modules definitely require additional work. personally i would still prefer the cookies module if the licensing could be negotiated with the maintainer. cookies looks like the more solid starting point never the less despite its numerous listed downsides / flaws.

I agree, I'd really love to go with Cookies, but the maintainer of the external component does not respond at all.

GDPR module .. extra dependencies

@rkoller I think it's nothing we should be worried about. Yes, there are additional dependencies, but that's pretty normal. And as we don't expect the user to install the modules themselves as we're doing it as part of the recipe, they won't get confused by either the long list or the overwhelming setting forms.

From my own tests, I could imagine that a combination of EU Cookie Compliance → (plus GTM and Matomo extension) together with the Cookie Content Blocker → and with the GDPR → modules could make a good combination for an out-of-the-box setup for Drupal CMS sites.

• Using EU Cookie Compliance to manage general cookie consent and to link to the default content that @boromino started to collect in 📌 Default content for privacy requirements Active
• Using Cookie Content Blocker to block remote videos, fonts, etc. until the users consents
• Using GDPR to mark PII fields for reports and "Right to be forgotten" as well as explicit consent agreements where needed.

All those modules require extra work, but they seem the best options that are currently available. We should try and polish them as much as we can for version 1.0 and also work with the maintainers on the longer term roadmaps.

When it comes to the EU cookie compliance, I just wish we could have something like only showing the banner if there is at least 1 cookie that needs consent. Because then, we could enable that module on all sites, and the banner would still not be displayed on 90% of all sites as they don't use cookies in the first place.

Unfortunatelly the 8.x version of the EU Cookie Compliance modules has a pretty annoying bug/feature: #3209352: 8.x: disabled_javascripts runs scripts which wouldn't otherwise be on the page → . In the 7.x version, only scripts which were removed by the module were added later. But in the 8.x version, this is not checked (see the issue I linked), so the module is adding all JS scripts even if some of these should not be on a specific page.

Thanks @poker10 for pointing that out. I'm wondering if the feature should be working based on libraries instead of javascript files. Then it would be possibl, again, to alter the list of injections. I'm having a meeting with Ramsalt later this week, then we can address that.

In general, once we have the list of modules that we want to go with, we should create list of issue that must be fixed and such that would be nice to have.

@jurgenhaas elinks is a text based web browser.

I guess, we could live with that.

I don't agree. Javascript cookies will not be set in a non-javascript environment. However, PHP cookies may still be present, but the website owner will not have any chance to ask for consent. Besides, I don't see any reason why consent can not be asked for without relying on Javascript.

@boromino is there any cookie consent management tool available that works without javascript?

Also, cookies that are set by PHP, i.e. by the server, seem to be technically required and therefore don't need any consent from the user. Maybe not entirely true, but probably pretty close?

@jurgenhaas @boromino that is what I briefly mentioned in our last UG meetup: IF some module in Drupal sets cookies (via the Set-Cookie HTTP Header) OR does any other GDPR-related stuff (e.g. tracking the behavior of authenticated users), then it should also be included in the consent management.

However, I don't know which modules would behave like that. The only occurence of the "Set-Cookie" header I am aware of is in the SessionConfiguration class - the session cookie which is clearly needed for functionality. So - is there any way of searching all contrib sources for possible other occurences?

Other cookies can only be set by javascript libs/apps or by embedding external media via iframes, both of which should be loaded only with the user's consent anyway. Or am I missing something else?

I can not get cookie content blocker to work out of the box:

• Applied patch from https://www.drupal.org/project/cookie_content_blocker/issues/3463065 🐛 Fix renamed export in CKE5 plugin Needs review
• enabled https://www.drupal.org/project/eu_cookie_compliance →
• followed instructions on https://www.drupal.org/project/cookie_content_blocker/issues/3203376 →
• added CKEditor icon to basic HTML format
• inserted remote video into cookie content blocker tag in basic page body field using basic HTML format

The video is blocked, but although "Allow all cookies" in cookie consent dialog is clicked, the video is never displayed, not even after page reload. Clicking on "Show content" button doesn't do anything. Also see https://www.drupal.org/project/cookie_content_blocker/issues/3119057#com... 💬 "Show content" does not trigger unblocking content for oembed video Postponed: needs info and further.

We've made good progress in testing and talking to module maintainers the last few days. And it seems to go the direction towards the Klaro module → which does consent management and remote content blocking in a way that meets all our needs.

We can now start building the base recipe for this and I've created an issue at 📌 Build privacy base recipe Active for that.

The second part should then be the data protection provided by the GDPR module, and the issue to build that advanced recipe is at 📌 Build privacy advanced recipe Active .

I'm in the process of building those 2 recipes and we should be able to test them out in the next couple of days.

No need for the "[feature]" flag. We already know it's a feature request. :)

We can now close this as the base recipe has just landed in 0.x - thank you everyone for your help in getting this done!

Automatically closed - issue fixed for 2 weeks with no activity.