What is purpose of LogItem model?

[Zagrebelin]

There are no fields like user_id, or session_id, or remote_ip, just datetime and accept\decline action, how could it be used?

[sergei-maertens]

Maybe to collect some statistics about which cookie groups are commonly accepted and which don't? I've no clue to be honest.

@bmihelac can you remember why it was added?

[fabienheureux]

GDPR compliancy requires you to keep track of user consents, in case of a control.
A few examples

• https://www.cookieyes.com/blog/cookieyes-logging-and-demonstration-of-cookie-consent/
• https://complianz.io/definition/what-is-proof-of-consent/

[sergei-maertens]

That's an interesting clarification! However I'm not sure how the current implementation (with just a accept/decline action and timestamp) can satisfy that 🤔

I wonder if emitting a log record (via logging stdlib) while including the request details wouldn't be a bit better approach. Users can then decide what they want to extract - request.user, request headers (to get the IP address) perhaps and set up their logging solution so that it's stored in a durable solution?

[some1ataplace]

The docs should be updated stating that this is a requirement by law to have some sort of logging being done on user acceptance/decline of cookies, whether that be at the LogItem table or another logging methodology as Sergei mentioned capturing User ID, Session ID, Remote IP, etc. If using Sergei's method of logging, the docs should include an example of how to do this and provide recommendations. The links Fabien included should be in the docs too. If using the LogItem table for logging, we should update the model to include these new additional fields.

I think the intention of the LogItem table was to capture the accept/decline cookie actions of the user for legal purposes just like the law now intends. I requested a while back to make an optional setting to turn off the LogItem table because it could be spammed by the users by clicking accept/decline over and over again, filling up the database excessively. I still think this setting to turn on/off the LogItem table should remain giving the user the option to either use the LogItem table or another logging methodology Sergei mentioned. To protect against spam, we would most likely need to check against an IP address to see if they recently already made an acceptance/decline. Since IP address is a form of Personally Identifiable Information, we would need to use encryption/decryption or pseudonymization to protect the user's identity. A username / user ID instead of an IP address may suffice if the user is logged in, but that still leaves out anonymous logged out users when tracking their consent.

Personally, I would prefer not to do any logging at all period, but still have the functionality to do logging and have it built in just in case if forced to do so. Most sites require cookies to be accepted to do anything, so it is generally implied that the user accepted cookies at some point, which makes most logging useless in my opinion. Maybe we should only track acceptances, as declines shouldn't hold any users accountable by the law. If the accepted users later decline, maybe their log records should be deleted. You can have a data retention policy with a django command cron job to delete the older records. These can all be customizable setting options. Either way, guess we all don't have a choice in the matter, and have to do some sort of logging.

[sergei-maertens]

I think we can conclude that:

• The current solution is not sufficient. Not for authenticated nor anonymous users. I just don't see how this is currently practically used.
• It's a complicated legal mess and likely there is no one-size-fits-all solution. Users would benefit from having it in the library so that they don't have to build their own solution over and over again.
• You can already disable logging now with a setting

However, since the topic of logging has not really come up before, how many people are actually being enforced to track and present logs? I'm all for doing things in the spirit of the law, but if nobody actually makes use of this feature, I have zero motivation to either properly implement it or even review any outside contributions.

I'm still leaning towards just using stdlib logging and emitting log records, and another package can opt to fill the space by defining log models/handlers to tap into the cookie consent log records that are emitted.

[some1ataplace]

I think we have to implement something and/or provide guidance on logging no matter what, whether we like it or not.

The major players in the cookie consent business (CookieYes, Cookiebot, Osano, Usercentrics, Onetrust, Trustarc, Cookie Script, etc.) have logging of acceptances/declines built in, but it appears to be an optional setting. This is probably because the major players realize their customers could make a choice to use the built in database solution or something else server side such as stblib to accomplish logging.

I think we should at least mimic what the major players in the cookie consent business are doing because they are our competitors and they have the money to pay lawyers to know what needs to be done on the legal side. There are some other cool features that these competitors have that we do not have that we could also implement, but like anything in business we should also try to innovate and differentiate from these competitors to give ourselves the competitive advantage.

https://www.cookieyes.com/features/ (plus the link from Fabien above)

https://www.cookiebot.com/ and https://www.cookiebot.com/en/cookiebot-cmp-features/ and https://support.cookiebot.com/hc/en-us/articles/360003782734-Where-can-I-find-the-consent-log and https://support.cookiebot.com/hc/en-us/articles/360003782654-Logging-and-demonstration-of-user-consents

https://www.osano.com/solutions/consent-management-platform

https://usercentrics.com/

https://www.onetrust.com/products/cookie-consent/ and https://my.onetrust.com/s/article/UUID-7fe84e03-290e-81f6-7f49-a47b8e07afd1?language=en_US&topicId=0TO1Q000000bHeJWAU

https://trustarc.com/products/consent-consumer-rights/consent-preference-manager/

https://cookie-script.com/record-visitor-consents.html