Cookie is set when 'read more' is clicked, is this inteded?

[JulianKuipers]

Hi,

First of all, thank you for this tool!

I have a question.

When a user clicks the 'read more' button the consent is automatically given as if the user has clicked the 'ok' button. Should this be the default behavior? Or should the user still click the 'ok' button to give it's consent after reading the privacy page? So clicking the 'read more' button does not actually set the cookie?

I hope to hear from you, thank you in advance!

Kind regards,

Julian

[undergroundwires]

Thanks @JulianKuipers ! It's a very good question. Happy to see that the library is getting actively used 🙂

Compliance perspective
GPDR is a law that has many interpretations but the common way that companies today sees is that it's about informing the users more than getting an acceptance. Most of the websites on internet set cookies anyway without getting an OK first and just show the banner to inform. So my thought was that if it's all about "informing" then if the users wants to read more (e.g. click on "read more") it's an active consent to be informed so the user gets rid of the banner as quick as possible 😀. I've seen this behavior on some other webpages working hard to be compliant as references, they might be wrong, I might be wrong, can be bandwagon fallacy trap.

Minimizing intrusion
Never seen someone who likes those banners, so that's why I kept it as little intrusive as possible in ez-consent. So decision to go with disabling the banner when clicking on "read more" was to minimize the irritation.

Do you think that we should allow the behavior to be customizable? 🤔

[JulianKuipers]

I definitely understand why you chose to make it work as is. In most of the cases that would probably be the expected way for it to work.

I think it would really be an asset to give the developer the option to choose whether the read more button should have the same behavior as the ok button or that it should only be informative and not give the consent of the user which they have to give after reading the privacy page (or straight away when the arrive on the privacy page). When a user is really concerned about the contents of the privacy page, it can leave. If they later (unknowingly) return, they won't see the consent banner again (since they 'already gave consent') and they might proceed on the page even if they did not want to. It is a little manipulative in a way.

But then again, this would be only applicable for the minority of usages.

Do you think that adding a boolean option more_button_gives_consent (or a better name) and based on that assigning a different handler to the read more button would do the trick?

[undergroundwires]

I understand your point and I agree that we should make the behavior of setting cookie optional. But I'd like to make it true as default to not break compatibility and keep "least intrusion" behavior of the library.

I actually liked more_button_gives_consent, a bit wordy but it shows the intention clearly.

But actually I think we should group setting in #2 and this one to something like this:

    more_button : {
        target_attribute: "_blank",   // Determines what the behavior of the 'more' button is, default: "_blank", opens the privacy page in a new tab
        is_consenting: true,          // Determines whether clicking on 'more' button gives consent and removes the banner, default: true
    },

Btw, prefixing it with is is something many developers would be familiar with. I should also refactor always_visible setting to be is_always_visible in backwards compatible manner.

How does it sound?

I'll publish version 1.2.0 with both #2 and this one once we're done with them.

[JulianKuipers]

Yes I agree with that, the default should be what is used most, and that is the way it already was. I really like the grouped options since they both apply on the more_button, very nice. Using is_consenting is definitely better since every developer will understand that it is a boolean option/variable. This sounds perfect, thank you very much!

[undergroundwires]

1.2.0 is up both with both flags 🎉

[undergroundwires]

Closing as this is tested and implemented