Supporting cookie consent - feedback wanted

[markdumay]

Laws such as GDPR and CCPA require users to give consent before storing non-essental cookies. Feature #1164 describes a potential open-source solution. Input / feedback about this proposal is much appreciated. Feel free to share your feedback directly in this discussion thread.

[d-oit]

Not an easy task. Because it's not all about the cookies. If you use, e.g. a contact page, you need additional information on your website.

This is my personal opinion:
https://cookieconsent.orestbida.com/
looks good in a first place.

If you use it like designed, you have to log it Germany and create a backend for the logging - e.g. use contact form, analysis (GDPR page)
https://cookieconsent.orestbida.com/advanced/consent-logging.html

If I need it for a personal blog without analysis, I would go for the minimalist solution and adjust this for hugo.

https://hugocodex.org/add-ons/cookie-consent/#manage-consent

In the end, I only need an "Allow" and "Allow only necessary" with a link to a page like this:
https://european-union.europa.eu/cookies_en

Get the used cookies with the browser or services like: https://www.cookieyes.com/cookie-checker/?ref=SB_03092019

If the mode switch is designed like this and saved only with explicit click on the checkbox - no consent is needed in my mind. User does explicit a logic - marked with a tooltip.

Discussion:
themesberg/flowbite-react#546 (comment)

commercial Website
I would use a service like Piwik PRO, ccm19, cloudflare Zaraz (for google) or anything else

[markdumay]

Thanks for sharing your thoughts @d-oit! It seems to be a tricky subject with sometimes conflicting opinions.

I imagine it would be helpful to implement some kind of consent-based loading of JavaScripts within the Hinode script logic. The cookie consent itself would have to be managed somewhere else, but at least, you would have a head start as a developer.

Basically, most of the examples I've seen include the scripts in plain text to prevent them from loading initially. A separate "loading" script then actually processes the scripts based on tag (category classification) and given consent. As Hinode bundles most of the scripts into a single file, this would require some modification.

I'm using Hinode as foundation for a custom commercial site, so I'll definitely look into the services you mentioned (e.g. Piwik PRO, ccm19, Cloudflare Zaraz).

[d-oit]

Thanks for sharing your thoughts @d-oit! It seems to be a tricky subject with sometimes conflicting opinions.

The consent logging only applies to Germany.

I imagine it would be helpful to implement some kind of consent-based loading of JavaScripts within the Hinode script logic. The cookie consent itself would have to be managed somewhere else, but at least, you would have a head start as a developer.

Definitely makes sense.

Basically, most of the examples I've seen include the scripts in plain text to prevent them from loading initially. A separate "loading" script then actually processes the scripts based on tag (category classification) and given consent. As Hinode bundles most of the scripts into a single file, this would require some modification.

Usually, Auto-Block must load first on the page or via data attribute. Yes, some modifications are required. LocalStorage js lang + dark mode switch could call a hinode global js api like "saveLocalStorage".

I'm using Hinode as foundation for a custom commercial site, so I'll definitely look into the services you mentioned (e.g. Piwik PRO, ccm19, Cloudflare Zaraz).

If they use ga a CMP is the best option.

CookieConsent v3 looks maintained and a good option for a start.

ga alternative: https://plausible.io/

[d-oit]

https://github.com/orestbida/iframemanager

This looks also promising

[markdumay]

Hi @d-oit, I've released an initial alpha version of the cookie consent support. The documentation is available here: https://gethinode.com/docs/configuration/cookie-consent/.

I plan to implement a few JS functions next, which will allow developers to interact with cookies considering consent (based on categories). The current critical scripts will use these functions too. Your feedback is welcome!

[d-oit]

ATM I implement the theme mode drop-down with a save button

Testable first version

https://github.com/d-oit/hinode/blob/colorSave/layouts%2Fpartials%2Fnavbar-mode.html 

Color.js

This is the only component that I need ATM.

After that I will to check your code.
The documentation sounds complexity with the Hugo staff after a quick check.

I made similar staff in a

<script src="js/cc.js" type="module"></script>

With switch case for the category and include script

[d-oit]

time to read and understand the docu. Great job 👍🏻

What I had not found in the docu without looking into the code:

• How to insert a js file without a hinode/hugo module for c.c.?
  Personally, I would like to have a partial to override the separate like the navbar-mode.html - act more like a component in react & co
  and had the change to insert js by myself instead of the hinode config

--
| {{- define "partials/defer-scripts.html" -}}

[markdumay]

Thanks for your review! I’ll look into the basic script integration without needing a module. The same applies to the integration of new critical scripts.

[d-oit]

Did you plan something link this in hinode?
https://orestbida.com/demo-projects/iframemanager/demo1/

Don't need it at the moment - but it's on my todo list.

[markdumay]

It's certainly a nice feature - I'll keep it in mind for now. I'm currently working on a basic integration of CookieYes, including API calls. This would hopefully be a starting point for other, similar cookie consent managers.

[markdumay]

I have released a new beta version of Hinode to improve cookie support. It turns out dynamic loading of the cookie consent manager's script was not working well. I made the following key adjustments:

• A new integration option called critical has been added, next to core and optional
• Modules can now configure an url to an external link, which is not bundled but referenced directly instead
• You can bundle "local" critical scripts by category as well

The documentation has been updated too. I shifted most of the technical details to the advanced settings. The following pages have been revised:

• https://gethinode.com/docs/configuration/cookie-consent/
• https://gethinode.com/docs/configuration/modules/
• https://gethinode.com/docs/advanced-settings/scripts/

Finally, I've released a new module to test cookie consent management with CookieYes. An integration example is available here: https://gethinode.com/docs/configuration/cookie-consent/#predefined-integrations. I'm using the same module in the Hinode demo site (https://demo.gethinode.com) and main Hinode site (https://gethinode.com) to iron out any issues.

Open items:

• Apply correct theme in CookieYes (visit https://gethinode.com/cookies/ in dark mode)
• Fix theme toggler and language selector when rejecting all cookies
• Support custom script arguments (key/value pairs added to the script declaration)
• Show informative message in select components when script is unavailable (visit https://gethinode.com/docs/components/video/#vimeo)

@d-oit feel free to reflect on the changes!

[d-oit]

The localstorage alternative set is probably to technical.

Possibly easierer to understand if cookie consent is active use cookies values instead of localstorage. In this way cmp could recognize the cookie and handle it by themselves.

[markdumay]

Don't you always need the arguments in the script template.

In this case this could a inline partial to override with a ownScript.html partial

<script src="{{ $args.link }}"

I'm not sure what you mean with that? The script template is invoked by Hinode each time a script reference is added to the page header or body. The partial utilities/InitArgs.html ensures the arguments are valid.

[markdumay]

The localstorage alternative set is probably to technical.

Possibly easierer to understand if cookie consent is active use cookies values instead of localstorage. In this way cmp could recognize the cookie and handle it by themselves.

In my experience so far, it appears most - if not all - CMPs are able to recognize session storage, local storage, and cookies. I used local storage and session storage in the API functions to clarify which storage mechanism is used. Local storage and session storage have a couple of advantages over cookies, reason why I chose them (as a more "modern" approach).

[d-oit]

Don't you always need the arguments in the script template.

In this case this could a inline partial to override with a ownScript.html partial

<script src="{{ $args.link }}"

I'm not sure what you mean with that? The script template is invoked by Hinode each time a script reference is added to the page header or body. The partial utilities/InitArgs.html ensures the arguments are valid.

On the smartphone ATM. Couldn't check it live. You are right that's was ta wrong template.

I was search for an easy way to include script in the html head

Personally I would like to override a inline partial with HTML instead of a config.

Examples with attributes scripts

<script src="http://CCM19ServerUrl/app.js?apiKey=1234&domain=1234" referrerpolicy="origin"></script> <script id="Cookiebot" src="https://consent.cookiebot.com/uc.js" data-cbid="00000000-0000-0000-0000-000000000000" type="text/javascript" data-blockingmode="auto" ></script>

sample include in head or baseof.html a partial:

{{ partial "head/head-first-script.html" . }}

<!doctype html>

{{ partial "head/head-first-script.html" . }} {{ block "head" . }}{{ end -}}

[markdumay]

Thanks for the clarification. What I could do is provide a configuration option to include additional custom arguments. They would be simple key/value data pairs added to the script reference. It would be an extension of the current external script declaration:

[params.modules.cookieyes]
    integration = "critical"
    url = "https://cdn-cookieyes.com/client_data/{ID redacted}/script.js"
    [modules.cookieyes.arguments]
        arg1 = "value1"
        arg2 = "value2"

The result would look like this:

<script src="https://cdn-cookieyes.com/client_data/{ID redacted}/script.js" arg1="value1" arg2="value2">
</script>

With this declaration you don't necessarily need to define an entire module. You can replace cookieyes with any name and the script would still be included.

[d-oit]

https://demo.gethinode.com/en/

Reject all

The dark/light switch do nothing.

🤔

[markdumay]

Yes, confirmed as a bug.

I need to rethink the current implementation and support graceful degradation. I read the discussion thread you shared earlier. The current approach is conservative, e.g. the language and theme are not strictly needed to work with the site and thus classified as functional.

The language selector is less of an issue, as this can be derived from the site's URL (when using subfolders for each language and/or the language set in the page header). However, the dark mode would be lost on each refresh or visit to another page. I think the best approach is to use the auto mode, which checks the OS and/or browser preferences when the cookie (local storage) is unavailable.