Show cookie acceptance date on settings box

[w3b-beweb]

As mentioned here

Iubenda cookie preferences

it seems that from january 2022, in Europe, we need to track/log cookies preferences, i.e. "which" and "when". It seems a little stupid requirement to me, as cookies are held in the client's browser and are under user total control, unlike the data provided, for example, with a contact form that are registered by site owner.

From my (non-legal) point of view, the settings box complies with the "which" aspect, while for the "when", it would probably be enough to print somewhere in the settings box, the date the cookieconsent control cookie was created, to show when the user has accepted the use of cookies.
What do you think? I believe that the acceptance date can be easily implemented and that it can also be useful from a legal point of view.

[orestbida]

Yes, adding a date field inside the cookie is pretty easy!

The date could be retrieved via a special placeholder, perhaps something like {{consent_date}}.

E.g. CookieConsent accepted on {{consent_date}} => CookieConsent accepted on 30/12/2021.

[orestbida]

I tried looking into this a bit more in detail and it is very complex.

Based on Iubenda, starting from January 9th 2022, you MUST be able to show a "Proof of consent" document — which can be easily generated if you were to keep track of all "Consent records".

A consent record should store the following data:

- who provided the consent (ip address?)
- when and how consent was acquired from the individual user;
- the consent collection form they were presented with at the time of the collection;
- which conditions and legal documents were applicable at the time that the consent was acquired.

You would very likely need a database, so that — when asked — you can show a "Proof of consent" document: a list of all consent records relative to a specific user.

Needless to say that this is beyond the scope of a simple javascript plugin!

Saving the above data (or something similar) into cookies/localstorage — or any other client side storage — will not fix this as the user can easily alter or delete it entirely.

[n3t]

I was solving this in my Joomla plugin, and I store the consent in simple log file using AJAX call to server, store the IP, date time, current revision and accepted categories. This "somehow" fullfills requirements, but generally it is not bullet proof, and it never could be. There is no way how to prove that specific person agreed / disagreed, unless you require visitors to make selfie while clicking your consent :)

When I checked other solutions, it is common to display Consent date time in settings dialog and usually also some generated UID, which could be logged on server side (at least bit better identification, than just IP). So maybe if there is just some UUID generated on every consent and stored in cookie, which could be logged server side, this could help a bit, everything else is, as you noted, completely beyond scope of this plugin...

[w3b-beweb]

@n3t Not only "There is no way how to prove that specific person agreed / disagreed," but at least half of the proof resides on the user's browser. Without user cookies there is no way to associate the user with the track in a database, and in any case the user can withdraw consent or delete the data independently at any time by deleting cookies. This makes this law requirements a great no-sense to me from a technical point of view.

[n3t]

@w3b-beweb yeah, it is non-sense as all of us know :) The point is to prove "reasonable effort" (as I was told by lawyer) to fulfill the law. So even the consent is generally non-provable, you have to show some "effort" if someone (some bureau) wants to prove it. Now is question what is "enough effort", but this is question for lawyers, not for technicians :) In my case I add some server side UUID generation, which I store in cookie also, it looks somehow as I spent "bigger effort"... Integration of UUID directly on client side, and showing it in Settings dialog would make this plugin look more "effortable", even we all know it is generally for nothing :/

[orestbida]

So, storing these new fields inside the cookie should be more than enough:

• uuid (probably generated using crypto.getRandomValues)
• consent_date
• last_consent_update

[yffaryffar]

On the FAQ page of the Italian Privacy Authority website, point 9 states that the owner of the site can use a technical cookie to keep track of the consent given. Point 8 indicates what the banner should show. For 8.4, I found a solution using header div tags, css and js 'click' event to act as "reject all". Do you think it could be the subject of a future implementation?

[orestbida]

I refrained from implementing the {{field}} placeholder, as it puts constraints relative to the date format and where you can use it (inside the preferences modal only).

You can retrieve any value stored in the cookie via the getCookie method and use in any section (e.g. cookie policy page) and format based on your needs using javascript.

The 3 above field names were changed to:

• consentId
• consentTimestamp
• lastConsentTimestamp

Available in v3 (beta).