GDPR compliant cookie consent dialog

[hschwane]

Hi,

since I am from Europe and want my site to be accessed by EU citizens I need to ask users if they are ok with the use of cookies. Adding a dialogue by default that that asks the user before any cookies / localStorage are used would be nice.

I have integrated the dialog from https://www.cookieconsent.com/ on my website and am happy to file a PR if you are interested. However It is not shown directly at the top, but below the menu bar for some reason. Not sure how to fix that.

[alshedivat]

@hschwane, thanks for pointing this out. It's would be great if you could send a PR.

To answer your question about positioning, the menu bar has the absolute position at the top of the page and keeps moving with scrolling. You can change that behavior in _config.yml by setting navbar_fixed: false (see line 27). If you send a PR with basic functionality, I can help with adjusting the styles a bit. Thanks!

[riccardo-degasperi]

@hschwane, thanks for this!

After implementing your changes, I've noticed that the page meta description displayed by Google search is 'We use cookies and other tracking technologies...'.
I guess this is because it is the first line of text that appears when you open the webpage?
Is there a way to change that?

Also, is there a way to style the cookie dialog box? Like changing the font?
I see that cookieconsent.com offers a bit of customization, but not much.

Thanks! (and apologies if this is the wrong place to ask)

[hschwane]

hmm that is not ideal for sure.
Maybe we can move the call to cookie-consent further down in the code?
I am not a web-pro and had some trouble myself getting it to work at all.
We can also use any other consent dialog provider if you have something that works better.
I also have still no idea how to get the dialog stuck to the top instead of scrolling with the content.

[hschwane]

@riccardo-degasperi

So I played around with this a bit, trying to add a data-nosnippet attribute (https://developers.google.com/search/blog/2019/09/more-controls-on-search#using-the-new-data-nosnippet-html-attribute), or moving the banner to the bottom of the page.
However, the cookie consent javascript seems to add the dialogue to the beginning of the section regardless where it is placed. So no way to surround it with other tags.

I think we need to switch to another provider, but they all work differently and most require the website owner to create an account. So that would mean to start over from scratch. The other option would be to roll our own dialogue.

[dag7dev]

@hschwane any progress? Did you fixed it in your PR?

[hschwane]

I did some research on different options but have jet to implement something. I will have to mostly rewrite my changes using a different provider for the dialogue. That should then fix all the problems with the current implementation. I will update you when I get some time to implement it. Hopefully next week.

[dag7dev]

I did some research on different options but have jet to implement something. I will have to mostly rewrite my changes using a different provider for the dialogue. That should then fix all the problems with the current implementation. I will update you when I get some time to implement it. Hopefully next week.

I hope it so! Keep it up!

(also: @hschwane you're not forced to answer me by email; however, some people are reporting me who my email goes straight to the spam folder for unknown reason. If it's the case, I just wanted to let you know that I have sent you an email and you could find it straight in your best spam folder! :D)

[hschwane]

Hi everyone,
sorry for the long wait. I updated the push request and most of the problems should be fixed now. It is using "ihavecookies" https://github.com/ketanmistry/ihavecookies now, which is open source (MIT) and therefore we can modify it directly if anything needs to be changed in the future.
I tried to edit the css to make it fit with the existing colour theme (light and dark), but you can change it of cause free if you want to style it differently.

So feel free to test the new version and post your feedback here, so we can fix any remaining bugs.

The only thing that is still not working is blocking of the twitter cookies. I created an issue with the twitter plugin ( rob-murray/jekyll-twitter-plugin#45 ) to get some help on how to do that.
@dag7dev since you offered to help, it would be great if you could look into blocking the twitter cookies. If you have some free time that is.

[dag7dev]

@hschwane are you sure is it possible by us?
I think the most appropriate solution would be something like "if I am using the %twitter% and I cookied-opt-out, then don't use %twitter% plugin", however I think in order to know if %twitter% is used or not, the plugin should tell when it's currently being used or the theme itself need to set up a variable each time it renders a post.

Despite this, I don't think the second way it is the most appropriate: not only you would waste resources, but in order to know when a %twitter% tag occurs, you should parse your page before rendering... I mean, it is a solution but I don't know if it's the best solution.

[hschwane]

@dag7dev The only thing we can do right now is the second option. Using JavaScript to remove the twitter script before it is executed. The problem with this is, that simply hiding the html is not enough. We need to prevent the actual twitter API calls from being executed.
And I completely agree with you, that is not a very nice solution. That is why I hope the author of the plugin will answer in the issue I created on their repository. Maybe he has a better idea.

[alshedivat]

Just catching up on this discussion.

@hschwane, thanks for providing an implementation based on ihavecookies! I looked through #223. It seems like to be able to correctly (un)block different types of cookies (all of which are third-party cookies) requires adding quite a bit of extra JavaScript (including adding it directly to posts or pages in some cases, e.g., when posts embed youtube videos or other external content). This approach will put some extra burden on contributors and maintainers of al-folio down the line.

By the way, the dialog from https://www.cookieconsent.com/ is similar in that sense as it requires to manually add ALL scripts that use cookies. So, if someone contributes a new feature to al-folio that uses cookies, the contributor would have to go and update the cookie consent dialog as well (or edit quite a bit of JS if ihavecookies is used).

Thinking about this more, I currently see only three options:

1. If we want to have cookie consent as a core part of al-folio (which can be easily enabled or disabled), it needs to be a service that automatically identifies and blocks cookies, without putting an extra burden on the contributors or maintainers. The hosted version of Cookie Consent by Osano is an example.
2. Another option is to provide a very minimalistic cookie consent dialog which simply says that the website uses cookies, without an option to opt-in or opt-out (e.g., see the open-source edition of Osano).
3. Finally, not have cookie consent as part of al-folio, and make the user responsible for figuring out whether they need a consent dialog and which service to use.

Let me know what you think.

[hschwane]

Yes, this is true. If you have a script is using a cookie, you need to test using an if statement in javascript, to check if the cookie is allowed. If you do not care for cookie consent then there is no need to add this if statement. The script will then always execute, regardless of settings. There is also an option to turn off cookie consent completely and just allow everything for those users who do not need cookie consent on their websites.

So yeah, I agree it will add a burden for maintainers. If you are a user and do not need cookie consent, it should not effect you much (just set the option in the config file to disable it and user your own scripts as you are used to). If you are a user and you need cookie consent in your country, my changes will make that much easier compared to implementing your own cookie consent from scratch.

Regarding your three options:

1. I tried using Osano, but could not get it to work properly. It would also require every user to have an account with Osano.

2. This would not be enough to comply with EU-regulations. As far as I understand, manual opt-in is mandatory.

3. That would be the easiest option for the maintainers for sure. However, looking at how much time it took me to get cookie consent working, next time I would probably just pick a different theme that has cookie consent build in. So this option might make the theme less interesting to potential users.

What my changes could do would be option 4. al-folio provides a consent dialog for build in features like tracking, comments and theme change. Users who do not need it can turn it off and ignore the code, and users who need it will have to figure out how to add their own cookies themselves. At least then they do not need to hunt down cookies all over the project and modify build in files.

[GabVenturato]

Hi! Any news about this feature? It would be really appreciated :)

[hschwane]

Hi,
so from my perspective this is already usable (as long as you do not use the twitter integration). You can pull the commits I added in the PR #223 and add them to your fork. I have no news from @alshedivat (other than what is in this thread) on whether or not he plans to merge that PR into the main repo.
Regarding the twitter plugin, I did not get any information from the authors (rob-murray/jekyll-twitter-plugin#45). Unless that happens I do not plan to experiment with this any further, as I do not use twitter myself.

[GabVenturato]

Thank you very much for your work @hschwane! I'll try to wait some more time to see if maybe @alshedivat has any plan to integrate the PR soon. Otherwise I think I'll pull your PR directly in my fork! :)

[alshedivat]

the best way to add GDPR compliant cookie consent is using https://github.com/orestbida/cookieconsent