Community discussion on how to assist Drupal site owners towards GDPR compliance?

Events happening in the community are now at Drupal community events on www.drupal.org.
baluertl's picture

As probably all you know, deadline of General Data Protection Regulation (GDPR) is coming (25 May 2018) and most probably it will affect almost all site owners. GDPR is an extremely wide topic: if affects so many fields of a modern website from initial architecture through continuous development even to final maintenance. Especially with such a proudly modular ecosystem as Drupal is, it's almost an impossible mission to provide a one-click-good-to-go or one-size-fits-all solution for them. (Maybe only Drupal core modules can be marked if they are relevant to the GDPR topic or not, but that's not enough.)

"There's a module for that!" – You probably have heard already this from many site owners, administrators or developers. That's the Drupal ecosystem is well-known about its extremely wide list of extensions (modules, themes, distributions) offered by its lively and active community during its 15-years-old history.

At the time of writing if you search for the term of "GDPR", will see 5 results. Some of them have an already useful feature, some others are just sandboxes. One thing is common among them: a clear vision about how would it be the best to assist site owners to get prepared for the GDPR compliance audits.

This is why I submitted this post, let's discuss together, share your ideas, express your wishlist, tell us the story of your client, or add any comments on this topic.

Comments

Hi Balu - thanks for creating

dubs's picture

Hi Balu - thanks for creating this group. Hopefully they'll be enough interest (and time) to get this moving as us poor GDPR country developers have a lot to consider!

We, at AnyforSoft and Drupal

pazhyn's picture

We, at AnyforSoft and Drupal Ukraine Community, within Global CodeSprint JAN 2018 Kharkiv started to contribute to feature requests:
https://www.drupal.org/project/gdpr/issues/2939990
https://www.drupal.org/project/gdpr/issues/2939995
small issue fixes:
https://www.drupal.org/project/gdpr/issues/2940056
https://www.drupal.org/project/gdpr/issues/2940043
https://www.drupal.org/project/gdpr/issues/2937684
and some idea to integrate with backup and migrate module:
https://www.drupal.org/project/gdpr/issues/2931820#comment-12453673

@Dubs Thanks for joining! I

baluertl's picture

@Dubs Thanks for joining! I agree, indeed, ideas behind GDPR raises a load of technical questions on both site-building, development and maintenance sides.

@pazhyn That was a nice surprise to see AnyforSoft how actively started to get involved. Thanks a lot for your valuable comments, especially the patches. We review them this week, so hopefully, we can open February with a publicly testable (and localizable) alpha release!

I've been reading GDPR docs

alextuchkov's picture

I've been reading GDPR docs for several weeks already and there are some points which we actually can do using single-module approach. And data sanitation is only one small thing in it.

  1. The first thing about GDPR is Consent.
    This means that each time user is sharing his personal data with the Processor (a website, app or a service) we need to ask him, whether he confirms that his personal data will be processed and stored by us. This should be done in a direct, transparent way. And this is applied to Sign Up and Forms.
    Possible solution:
    We need to do something like these modules:
    https://www.drupal.org/project/gdpr_consent
    https://www.drupal.org/project/gdpr_compliance
    A sort of a pop-up screen with editable text and opt-out. And if users states he does not agree - we shouldn't process this data.

  2. The Rights to Access
    We need to a User with an ability to see which exactly data is processed and used. Basically, I think this can be a user page with some notices that:
    Email field - this is Personal data and we XYZ are processing it.
    In the default Drupal state, User doesn't have a straightforward way to do that.

  3. Data Portability
    A user has a right to request a full list of data being used and processed in some format - for instance .csv (it should be a common format which can be read by other services). We’re talking about only personal data (Name, email, phone), not the activity logs.
    And after that user can transfer this data to another service.
    Basically, this can be done as some "Export" button which will generate a file with his info.

  4. Erasure
    A user has a right to manually request data Erasure from the website. Not only switch-off the account, but totally delete data from the DB.

  5. And there are some general notices that we shouldn't process data we won't use. For example, if we won't use the phone number in any way, we shouldn't gather it on Sign Up or via the Feedback form.
    We should use SSL, firewalls and in general create projects with built-in Privacy approach.

As you can notice, the data obfuscation is not a goal. It's just a way to secure data. However, if projects won't comply with the Right to Acess, Erasure and Portability the fines will be still applied.

Let me know if these comments give you a bit of an overview. I will be happy to create feature-requests for the module.

Consent to be tracked?

damienmckenna's picture

The first thing about GDPR is Consent.
This means that each time user is sharing his personal data with the Processor (a website, app or a service) we need to ask him, whether he confirms that his personal data will be processed and stored by us. This should be done in a direct, transparent way. And this is applied to Sign Up and Forms.

How would this work with the bazillion tracking services that sites use? Does it mean that tracking JS shouldn't be loaded until after the visitor has confirmed it? And then, would it need to happen on every page request too, or would it be allowable to store a cookie to log this?

Hi Damien, No, the GDPR is

alextuchkov's picture

Hi Damien,
No, the GDPR is referring to personal data - info based on which we can verify the user personality. For example, if I give you an email: alextuchkov@anyforsoft.com and my phone number +380930000000 - and you will google it and will find my full name, social status etc. This is personal data.
User logs, as far as they are not gathering real personal data are out of scope. At least from my understanding.
Though, GDPR is also forbidding using any data for Profiling and Scoring. So, it's forbidden to use any date in order to grand me some credit limit, or something like this.
Answering your question - we should be more careful with gathering cookies and other user log activities for sure. But as far as we're not gathering personal info - we're ok.

I would disagree on user logs

fgm's picture

I would disagree on user logs being out of scope. The GDPR, from reading the actual regulation, is much more extensive than any other existing regulation, and should not be confused with ePrivacy requirements, which will be the next big legal topic once GDPR is at cruise speed.

Could you maybe point out why

alextuchkov's picture

Could you maybe point out why action logs which don't contain a reference to an actual user data can be treated as personal data?
For instance, if we have a record that user id 0001 has visited page /node21 at 2017:01:30:12:00 - doesn't look like a personal information.

The definition of "personal

ggitsels's picture

The definition of "personal data" that enters into the scope of the GDPR, is very extensive and notably includes identification number and online identifier. See the definition below:
‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person

IP addresses count as

yautja_cetanu's picture

IP addresses count as personal information. Especially if they can be tied to a user at any moment later (like a comment includes some PII)

The error logs include IP addresses and that is included to some degree in user logs. Also "Flood" includes IP addresses for flood control although as that tends to exist for a small period of time it can probably not be included in GDPR

Let's not forget issue

fgm's picture

Let's not forget issue https://www.drupal.org/project/drupal/issues/2848974, which contains a bunch of ideas and remarks, especially following the GDPR BOF at DrupalCamp Lannion.

If only personal data fields

dmiric's picture

If only personal data fields like username, email, full name and such are part of this regulation. Then the first step in this process could be to simply obfuscate users that want to be forgotten.

Lets say someone requests his personal data to be forgotten and we just make a small module that replaces username with forgotenuser1 email with forgotenuser1@somesite.com so on, and then simply block the user.

Would this be a good enough method to solve forget me function?

Removing orders from commerce or other data that is referenced by user could be pretty hard to do.

The other problem I see is what happens if you periodically backup your database. Then the backups would still contain that data. In case you need to go back to backed up database you may get the data back, not to mention that you realistically still have the data.

EDIT: This is not possible since uid has to be deleted too. Ty @ggitsels for clarification

Note: Only Personally

yautja_cetanu's picture

Note: Only Personally Identifiable information needs to be forgotten. So when removing information from orders only the things that identify who they are.

Therefore I think we need at a Field API level some way of knowing which fields need to be forgotten, which user they are tied to and how they should be forgotten. (Whether the field should be obfuscated as you've shown above, or whether or not a member of staff needs to manually check the field for example with a "Notes" field, or whether its just fine)

Therefore we need to trace back from the user to the order and also obfuscate the information on the order that is GDPR compliant.

  • Regarding backups. I think we need to build a tool that keeps track of all users who have asked to be forgotten and keeps their User IDs tracked. When you restore a backup you will then need to have an automated script that goes back and removes all that information.

Commerce solution

graber's picture

I'm currently working on a solution for Drupal Commerce, only the D7 version is sponsored but it may be a good start for D8 as well if others find the approach adequate. The module provides a way to anonymize personal data. https://www.drupal.org/project/commerce_gdpr

CLUSIF GDPR compliance chart

spyrosk's picture

The French Information Security Club (CLUSIF) has published the following overview chart to help with GDPR compliance: https://clusif.fr/publications/infographic-personal-data-has-entered-the...

Good video on the topic

jyraya's picture

I recommend to every body to view this video: https://www.youtube.com/watch?v=bfOWTpY5_nw&feature=youtu.be

It is a session of the DrupalCamp Nordics 2017 presented by Kalle Varisvirta and he gives some usefull information.

As Part of Core?

mgifford's picture

I've set up this issue to look at bringing this into Core for D8 - https://www.drupal.org/project/drupal/issues/2848974

Have links there to other sites too. One warning I've seen from another list is that it's not just about European & international organizations needing to comply. If you have members who happen to be EU citizens, then you are subject to GDPR. Yes, it is unlikely that a tiny organization will be first on the list for enforcement actions, but GDPR is deliberately very far-reaching.

Seems to me that there is also an opportunity for the open source community to step forward and be proactively pro-privacy, especially in response to Facebook-like approaches to privacy.

Training offer from Exove

lizzjoy's picture

I've learned that there's a GDPR training from Exove so I'll share here. Feel free to pass it on and/or contact them if you are interested. https://www.exove.com/gdpr-training/

Drupal.org

mgifford's picture

@lizzjoy can you give an update for https://www.drupal.org/project/webmasters/issues/2953844

Is Drupal.org going to meet the deadline?

Slides of module comparison

baluertl's picture

Yesterday on DrupalCamp Transylvania I presented an overview of the currently available contrib modules in relation to GDPR requirements. Please find my slides here: https://goo.gl/5HhFVJ (The session was recorded, but I guess it may take a couple of days for organizers to edit and publish the videos.)

I hope you find it useful when you do the mapping between requirements articulated by your legal consultant/DPO based on the given situation and the contrib solutions currently available on Drupal.org.

Do you know if the video is

nickbits's picture

Do you know if the video is online yet? Can't see it.

Drupal GDPR Compliance Team

gisle's picture

This community project is intended to serve as a locus for the Drupal community to discuss and coordinate efforts to improve Drupal's framework for GDPR compliance.

The project page is: https://www.drupal.org/project/drupal_gdpr_team

Legal

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: