RFC: It should be possible to switch off logging (GDPR related)

[donker]

Description of problem

Under GDPR IP addresses are part of personal data as well as url referrers, etc. This means the approach should be "no, unless". I.e. don't do this unless you have a good reason. Logging is part of this.

We log because after a security issue we must be able to determine what happened, how it happened, etc. So we don't log just because we can. But GDPR mandates that if we do this it is mentioned in the privacy statement/terms.

If a user wishes to completely disable logging there is no method for that now. So in the scenario where someone wishes to avoid any GDPR exposure, we cannot guarantee that.

Description of solution

A master switch for logging. By default it is on. Switching it off would effectively switch off all forms of logging in the platform that contains any personal info or link (user id for instance).

Description of alternatives considered

We can also opt to encrypt sensitive data. But that requires more work to find out how this would work.

We could also add an expiry date to logs. This would go a long way to comply to GDPR as you can claim to log no more than a week for instance.

[sleupold]

Please be aware that IP address is considered as personal data, as it allows to trace user activities, especially, if combined with external profiles. For any user tracing performed by the website or a partner (like Google Analytics), the user needs to agree, any just technical logging should be documented and ideally explained in Privacy Statement as well. This does not need a user consent, as there is a real "need" by the website owner.

[sleupold]

to be clear: GDPR defines multiple alternative requirements to store personal data:

• either the user did consent
• there is a need by the site owner or host
• legal requirements
  Storing server data to detect a hacking attempt is a "need", same to store IP address of a shop customer and his delivery address.
  However, this is a process of handling user data, a site owner needs to document and have rules in place to make sure, this data is not accessible by unauthorized people and gets deleted, when there is no need any longer.

[donker]

Please be aware that IP address is considered as personal data

That's literally the fist statement of the problem description. Just sayin'

To the specifics here, though: at a very high level GDPR asks developers to change their mindset from "let's store unless we have a reason not to" to "don't store unless you have a reason to". I'm trying to make that flip here. I have sites with IP logs dating back 5 years. Do we have a portal setting which allows an admin to set a time limit to this kind of logging? Or is that considered bad security?

[donker]

Note also that we capture the IP address before we know who it is. So if you have no consent (like an anonymous user) it is still registered.

[mitchelsellers]

Note also that we capture the IP address before we know who it is. So if you have no consent (like an anonymous user) it is still registered.

This is the point of the other discussion, IP can be addressed by Privacy Policy, not explicit consent from a logging activity.

To the specifics here, though: at a very high level GDPR asks developers to change their mindset from "let's store unless we have a reason not to" to "don't store unless you have a reason to". I'm trying to make that flip here. I have sites with IP logs dating back 5 years. Do we have a portal setting which allows an admin to set a time limit to this kind of logging? Or is that considered bad security?

Retention rules are not a big deal, but the key will be to limit access to who can change them, as you wouldn't want an exploit situation to allow a user to clear the logs.

[sleupold]

"Changing the mindset" is for sure the main goal of GDPR, not only for developers but to anyone processing personal data (for us: the site owners). But giving out target group, we need to be the ones putting them on trail regarding their websites. And there are a number of items in DNN, we need to change, like number of log records stored in the database and in log files. IMO core messaging is the next big area, where users currently cannot delete messages, even if they want.

[sleupold]

to be clear: GDPR does not disallow logging or bind it to user consent. If there is a business need, personal data may be stored and processed, but this needs to be documented and there needs to be a cleanup procedure. For the DNN EventLog, I suggest the following improvements:

• an admin option to anonymize IP addresses, e.g. by suppressing the last block.
• review the log types, whether current UserID is necessary to be included in the log
• provide proper cleanup of EventLog entries. currently, there is only a "number of items retained" per log type, IMO we should add a max. age for items as well (as I am using in my TurboScripts, following a suggestion from Bruce Chapman, which has never been included in DNN)

[mitchelsellers]

@donker Do we have an update on this based on the research/implementation that you have done for GDPR thus far? Can this be closed or is it still a need?

[valadas]

@mitchelsellers @donker this issue was closed and reopened, did you guys discuss this offline, do we still need this issue or can it be closed ?

[mitchelsellers]

We haven’t had a comment on this in 3+ months I’ll close for now. If it is decided to implement a new issue can be opened for implementation.