RFC: GDPR Data Processing Consent

[donker]

Request For Comments

Please review the problem and suggested solution and provide your comments to help drive this feature implementation into a future platform release.

Description of problem

To comply with European GDPR regulation a website must get approval from the users it stores data from for this data storage by asking them to agree to the terms & conditions and the privacy statement (further referred to as tac/p). The checkbox must be unchecked at first requiring the user to tick the box to sign. When the tac/p changes the user must be prompted again in the same way to agree to the modified versions.

Description of solution

1. Allow the website to specify pages for tac/p much like we do for login/registration pages. This will allow the administrator to use an HTML module which keeps versions of texts plus a log of when something changed. This will help downstream in determining which agreement the user has agreed to.
2. Add "HasAgreedToTerms" (bool) and "HasAgreedToTermsOn" (datetime) to the UserPortal record.
3. In the privacy tab of the site settings a new section should be added for this with
   • a switch to switch on the functionality for the site
   • a button allowing the administrator to rerequest agreement after a tac/p change. This effectively resets all "HasAgreedToTerms" to false.
   • settings to determine what happens if a user does not agree to the conditions.
4. If a user after login needs to agree to tac/p then they will be redirected much like they do now to the profile page. Either this or a popup should show to the same effect. Let us know what you think.
5. When a user registers the profile page should already show the tac/p agreement checkbox.

To be determined

To date I've found little on the scenario that doesn't follow the default one. What happens if the user does not agree? Should an account be deactivated? Marked as deleted even?

[trouble2]

I thinks there should be a checkbox in the site / user account settings, just like 'require valid profile'. So something linke 'require consent'. Whenever someone did not check the 'consent box' there is no way to continue

[mikesmeltzer]

A few questions:

Would sites be affected for public users that do not have login? If so, are we suggesting on creating users for everyone that comes to the website that submits a contact form for?

Is data storage considered even the IIS logs that can record IP addresses, what page / URI they have requested, etc.?

What if the user added a different module to the page and not the HTML module? Would the page support this?

Are we looking at building this as something extension developers 'could' tap into but would have to update their modules for support or more of a generic system that could be toggled on for overall site privacy?

Would child portals have a separate implementation or would they be governed by their parent portal?

[donker]

Would sites be affected for public users that do not have login? If so, are we suggesting on creating users for everyone that comes to the website that submits a contact form for?

No. GDPR is specifically about collection of personalized data. So without persona - no GDPR requirement.

Is data storage considered even the IIS logs that can record IP addresses, what page / URI they have requested, etc.?

In theory everything falls under this that can be traced to you personally. So a personal IP address may be the case. But a pubic IP address (i.e. when you're surfing from a Starbucks) I guess would not fall under this.

What if the user added a different module to the page and not the HTML module? Would the page support this?

This is why we opted for the solution: have configurable tac/p pages and record the date of signature. We'll leave it to 3rd parties if they want to do something more fancy. At least the framework will cover the basics.

Are we looking at building this as something extension developers 'could' tap into but would have to update their modules for support or more of a generic system that could be toggled on for overall site privacy?

The basics will ensure you can be GDPR compliant with DNN out of the box. My guess is that not consenting means no access to the site (this could be a switch). Then module developers could tap into the data and for instance figure out if the current user has consented to data. But I wonder what the use case would be as non consent is virtually the same as saying: please delete my account as data is stored in your DNN user account. Maybe a GDPR expert can elaborate on this.

Would child portals have a separate implementation or would they be governed by their parent portal?

For now the proposal is per portal. I'd love to hear from the experts if partent/child portal is possible to cover with one consent.

[mikesmeltzer]

The IP address can be logged into the Event Viewer for general exceptions, etc. So I think we would want to make sure this is taken into account - are there other areas too? I'd suggest treating an IP and as IP and not discussing if it is a shared one, public or private. Make a hard rule that we cannot store IP's.

In regards to IIS logs, we can't control that through DNN (we technically can in the web.config but probably shouldn't) so probably would want some best practices for suggesting to users how to configure IIS to become completely compliant?

[donker]

Indeed our technical responsibility ends with what we can do. The plan is to have comprehensive GDPR documentation as well (not part of this RFC) which could include the part about IIS.

Source about logs: https://www.ctrl.blog/entry/gdpr-web-server-logs

[mitchelsellers]

Based on the information in the regulations and the legal review that I've done, logging IP Addresses for exception tracking or other security stuff is ok, and I would NOT want us to roll something into this that would restrict it. For malicious situations that information is imperative to have recorded.

Also, for a user that doesn't agree to the terms I believe they would need to be logged-off.

[donker]

Based on the information in the regulations and the legal review that I've done, logging IP Addresses for exception tracking or other security stuff is ok, and I would NOT want us to roll something into this that would restrict it. For malicious situations that information is imperative to have recorded.

From what I read it's not that simple. What we could do is (1) have a switch for logging, (2) hash the IP addresses (i.e. only allow analysis on how many times you were accessed from location X, but not being able to identify it) and (3) ensure that the log is rolling and not accumulating forever. Possibly all with switches.

The fact is that the system is designed to help us when under attack. But for this we log all the time. My reading of GDPR is that the approach should be by default not doing this and only when needed log.

[mitchelsellers]

From what I read it's not that simple. What we could do is (1) have a switch for logging, (2) hash the IP addresses (i.e. only allow analysis on how many times you were accessed from location X, but not being able to identify it) and (3) ensure that the log is rolling and not accumulating forever. Possibly all with switches.

The fact is that the system is designed to help us when under attack. But for this we log all the time. My reading of GDPR is that the approach should be by default not doing this and only when needed log.

This is one area that is really hard to document. As under the guidelines of privacy security is compromised. Given this is a unknown area, I would NOT want to include this into the mix, at this time, especially since this is still possible/probable on all sites due to IIS.

[donker]

Call me naive but is it not more "removing a forensic tool" rather than "compromising security"? And if it is mandated by GDPR does it not behoove us to at least provide a switch so users can comply?

But I agree it could be its own RFC rather than fall under this one. So do you want me to create another RFC for this?

[mitchelsellers]

@donker The concern here is that if it is a "switch" if it is turned off, and a compromise happens, it is too late. There are key areas that we have to log IP's for, financial transactions, etc.

I'd prefer to move this to an RFC, as it would get really grey if we give a switch to disable it, but at IIS and otherwise it is still logged and confusing.

[donker]

RFC for logging stuff here: https://github.com/dnnsoftware/Dnn.Platform/issues/2435

[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 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.

Don't mix up with sites, where the user creates a local user profile and may be tracked. Handling of this data needs to be explained in Terms of Use and Privacy statement and the user needs to agree. If we want to support multiple versions, we should store consent to each in a dedicated table, IMO this is cleaner than using UserPortals table, and the admin may specify, how to maintain this data (keep the last two versions or keep back to 2 years). There should be a mechanism to turn the consent requirement off, e.g. for an intranet site.

[mitchelsellers]

@sleupold THANK YOU! Your verbiage was what I was looking for earlier today and I couldn’t think of it. It was the justification for Privacy Statement for this stuff. Google Analytics etc requires consent, but internal doesn’t;.

[BravoSierra]

Article 13 is about the information we must provide when collecting date. Shoud we have these 4 fields in the site settings? (and display them in the login page):

Information to be provided where personal data are collected from the data subject Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:

(a) | the identity and the contact details of the controller and, where applicable, of the controller's representative;

(b) | the contact details of the data protection officer, where applicable;

(c) | the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;

(e) | the recipients or categories of recipients of the personal data, if any;

[BravoSierra]

About logs: I agree with all the comments above. The fact is, logs can be considered compulsory, under Article 32 Security of processing. (- attached the NIST document, chapter 5.1.2 and 5.1.3 that is still a reference for logging best practice)

1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: nistspecialpublication800-92.pdf

.../...

(d) | a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

[BravoSierra]

For information, the 4 points under Article 32 Security of processing: ( (d) beeing the more relevant to logs justification because how could you evaluate the safety of the website if you didn't have logs)

(a) | the pseudonymisation and encryption of personal data;

(b) | the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

(c) | the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;

(d) | a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

[donker]

If we want to support multiple versions, we should store consent to each in a dedicated table, IMO this is cleaner than using UserPortals table, and the admin may specify, how to maintain this data (keep the last two versions or keep back to 2 years). There should be a mechanism to turn the consent requirement off, e.g. for an intranet site.

OK, this is where I beg to differ. My approach described above is minimalist. Yes, it'd be nice to have a dedicated table, but it will lead to a lot more code to maintain and I just do not see why we should go that far. Instead, we should leave the door open to 3rd party vendors who want to do something very advanced. For most sites it'd be more than enough to know the user has consented or not. We add a very basic logging system where you at least track when the last time the user has agreed and a way to reset all consents in case you've updated the tac/p. We'd also be able to leverage the event log for history. I do not feel comfortable, however, adding a shitload of code for the special case you mention.

[sleupold]

@donker Is it really a big deal to handle an extra table, after we are using PetaPoco? We only need to Create Table UserPortalPrivacyConsent (UserID, PortalID, Version, CreatedAtDate) with PK (UserID, PortalID Version) and FKs to users and portals table, as well as stored procedures AddPortalPrivacyConsent(UserID, PortalID, Version) and SelectPortalPrivacyConsents(UserId, PortalID). This would also result in a better schema, as reference table UserPortals is not used for log purposes and it is clear that UserPortals.LastUpdated does not refer to this information. You may even limit the records to one per userportal in platform but would make it easy to extend by 3rd party modules. I volunteer to provide necessary SQL code, if it helps.

[mikesmeltzer]

Could you use the existing Content Item API and store it in there? Versioning and workflow can be added with minimal effort too. Best part it already exists 👍

[sleupold]

      Could you use the existing Content Item API and store it in there? Versioning and workflow can be added with minimal effort too. Best part it already exists 👍

I would not consider a single binary value to be a typical content item - I see limited use of including it into search index, for example.

[mikesmeltzer]

A content type and an associated item is just a model of data. That data could have 1 property or many. It may not be an appropriate option for what you have in mind but something to consider.

[sleupold]

@mikesmeltzer, we are considering, how to store "Data Processing Consent flag" and timestamp for each user. IMO, this is more or less just a user profile property "readOnly" (not editably by the user himself), which would be easiest to implement than multiple fields for userPortals table, but even UserProfile does not retain a history by default (for my clients, I created a simple solution using a table trigger in the database, populating a ProfileHistory table, which is optionally including a digest of changes - old value and new value - being emailed daily to sync an offline member directory).

[mikesmeltzer]

I was giving an example. In this case, the data would be what you just described. My thought was because of the history and workflow capabillties built in it already that it's not a bad generic area to store things, very underutilized area in my opinion. Though, as Peter mentioned above, there are other places like the event log that could be utilized for parts of the solution and with the HTML module, etc.

I would weigh the pros and cons of the different approaches and try to get the best solution that could be achieved in minimal time with minimal risk in the short term. Using solutions that already exist, whether that's an HTML module or something else that could be implemented with some documentation might be a good approach to get a win on the initiative. Longer term solutions could potentially be implemented 'better' if they are planned for in any API rebuilds in the future.

[edisfera]

Going back to the main question about consent posed by donker, I think that:

1. there should be a site-wide privacy notice and a JIT (Just-In-Time) Notice for each form used to collect personal data
2. the JIT Notice should not be modified after the consent is acquired but a new consent for additional purposes of treatment can be acquired afterwards
3. consent, date of consent and the consented text should be stored

Let me explain the above points. A distinction should be made between the Privacy Notice and the JIT Notice shown on a form. In other words they usually should not match, the former being a broader statement made to a data subject that describes how personal information are collected, used, retained and disclosed; the latter being a mere disclosure of specific information practices posted at the point of information collection. A JIT Notice is part of the Privacy Notice. So, there should be a Privacy Notice page for the site where a company explains its policy and position about Privacy as a whole and a JIT Notice for each form used to collect data from a user (data subject) explaining, for example, the purpose of the collection of the personal information in that specific form and the intended treatment. The purpose of collection cannot change once the consent has been collected, but one could add other purposes for the treatment. In this case a new consent must be acquired for the new purpose before the treatment takes place (and if consent is not given, the treatment shall not take place and the user should not be deleted or logged off by virtue of the consent already acquired). In the hypothetical event that the original purposes is changed, than a consent must be acquired before the data is collected and treated as if the process of acquisition were starting anew: it is clear that in this case the data controller is not supposed to own the personal data of the registered users at all and should immediately delete all the acquired personal information, unless a consent request campaign is carried out in a reasonable short time in order to re-establish a valid legal basis for processing (the consent). Waiting for the user to log-in to acquire the consent is not an option. Finally, when storing the given consent and the time of the given consent, I would add the JIT Notice text (or a reference to it in a manner that one can demonstrate what notice the data subject consented on, specially if the text can be amended after the acquisition of the consent) since, in case of investigations by a DPA (Data Protection Authority) or litigations, one can better demonstrate the acquired consent.

[donker]

As to the above post: I'm trying to match these demands to the technical environment we're in. As a framework we are not at the "form level". Forms are in general part of modules. And the data processed in those modules is also part of what a third party delivers in the module. It is hard to see how the above has a bearing on our current effort.

It is not inconceivable that DNN would provide "mechanisms" within the DNN API to help module developers provide common functions. Think of the various interfaces (e.g. search) or providers (e.g. HTML editor). But these extension points take a lot of time to discuss and prepare. It is a much more invasive proposition than to focus on the framework first (as is proposed above).

[edisfera]

Hi donker, you are right that you cannot provide support to module development for being compliant to the GDPR (DNN is a fremework not a turnkey solution). But the fact that DNN provides a registration process (forms, tables to store user data and profiles) in its framework, not mentioning the privacy and terms of use statements (that, as far as I understand, in 9.3 should become configurable pages like the home or the registration page, etc.), implies that still some effert need to be done if DNN wants to be a CMS used by UE Companies to develop web centerd solutions or by overseas Companies willing to deal with people based in UE. Have I lost the point of your initial question or are you talking about accounts of registered users?

[donker]

I'm referring to accounts of registered users, and yes this means there is a form of the profile that users fill in. But what you describe above to me seems overkill given the requirements I've read. If it really means all of what you've said I think it's safe to say that will never happen because I can't see (a) a team of people that are willing to create such an elaborate solution and (b) getting the Americans to agree that so much new code will be added to the system to comply with a EU law. You need to keep in mind that whatever we decide needs to be doable in our current configuration of open source. I.e. by volunteers. And these volunteers need to be highly skilled so as to make the code blend well with the current framework and even then it is never guaranteed the code gets accepted. In that environment it's very hard to get people to work on it.

[edisfera]

I am sorry I caused so much distress answering your request. Of course the decision to make DNN compliant with GDPR it's not up to me, I was just trying to give my contribution on this matter so that if things should be done, let's have it done the right way from the very begining. Just one last aspect I'd like to draw to your attention: GDPR is not only a EU law. Of course technically it is, but the scope and impact also affects anyone willing to do business within the EU territory. So the real question is: how much strategic is EU to DNN? If it is, then the effort should be done to comply with GDPR (incidentally, don't think US is free of privacy laws that are quite similar to the GDPR or the culture of privacy is missing, just have a look at the IAPP website to understand what I mean) beacuse when a company (or a person) needs to take a decision on what platform to use to base its venture in or directed to the EU territory, he/she for sure will have to consider, among the others, the privacy readiness of the solution. If I can assist you in any way, please don't hesitate to do so.

[donker]

Point taken. And it's not that I was upset or anything. I'm just trying to wade through the various bits of regulation that are thrown about and making sense of it and then seeing what is realistic.

I love the approach "if we do X then let's do it right". I totally agree. But what may have gone unnoticed to many is that there was a push for GDPR a while ago which was abandoned. In part because it ballooned into something no one was willing to take on. As a result we missed the deadline to get something into DNN in time for GDPR regulation to kick in. I've been a strong advocate of doing something and doing it for 9.3. I am volunteering to spend a week or so coding something for this, but if it turns into man-years of coding I will also be forced to throw the towel into the ring.

Also I should mention that I feel strongly that the platform shouldn't try to do everything. I.e. it is fine if the platform covers only the 95% use case as with our extensibility model we can always have others jump into the remaining 5% and make some money off that.

Your remarks stay here in this thread for reference and maybe they get swept up in what we'll do. I don't know right now. Regardless I thank you for your contribution.

[BravoSierra]

GDPR is pragmatic. Consider sentences like below. So let's make it simple and a 'proportionate effort' to our purposes. That's GDPR state of mind and what we should do. It is not our responsability to "make DNN compliant". It's the controller's responsability in the context of the website to decide what is important or not. Our role is just to give them simple tools to help them be compliant. And turning this effort into a marketing tool saying "yes we care"

article 14 : Paragraphs 1 to 4 shall not apply where and insofar as .../... the provision of such information proves impossible or would involve a disproportionate effort, etc

article 32, Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons ... etc

[edisfera]

Hi BravoSierra, that is right the controller or the processor are responsible for being compliant. I also agree that DNN should provied means to make website or web solution based on its framework compliant (privacy by design). Again, considering the initial statement (where the question was not about making DNN as a whole compliant but about the handling of consent when collecting personal data and how to behave if the privacy notice should change). Instead, I am lost when you cite article 14 (that is about information to be provided where personal data have not been obtained from the data subject) and 32 (that is about security of processing)... I don't see how they fit on the topic of consent for data collected from the data subject.

[BravoSierra]

You are correct, I was not quoting the articles for themselves, just to illustrate the fact that in many parts of the text, the GRPR is pragmatic and requires to be contextual, to keep common sense, and act on a best effort basis. This is very surprising and disturbing for lawyers, who are used to answer with booleans when their customers ask if this or that is permitted or not. With GDPR oftentimes the answer is "it depends". This is why I think we can do it both "right" and "partially", without trying to consider all use cases. If we can deliver little tools incrementally, possibly version after version, then its ok. Let's not scratch our heads about hard deleting everything in the database when a user un-registers and difficult challenges like that. Yes theorically we should, but not if it is beyond a reasonable effort and cost. Let's consider GDPR as a state of mind or a process rather than a strict law that should be blindly enforced. Just what I tried to illustrate with these quotes.

[valadas]

In my opinion, the framework needs to provide 3 things to modules.

1. A way for the module to know if Enhanced privacy (gdpr) is enabled or not, this could be a simple host setting boolean.
2. A way to notify a module that a specific user wants to export his data (this could be very similar or an extention to the existing IPortable interface, we just need to add the UserId.
3. A way to notify a module that a user wants his data deleted.

The rest of how any module handles those events would be up to the module developer.

[mitchelsellers]

Changes in support of GDPR are currently in place, closing this item as it is no longer relevant to the functionality that we have in place.