Drupal modules that may require extra work to be GDPR compliant

Added SAML SP 2.0 Single Sign On (SSO) - SAML Service Provider → to the list.

Upon uninstall, the module sends personal data to an external site that is probably located in a country (i.e. India or USA) that does not have adequate data protection laws. It also do so without informing the people who are using it about their data being exported and without obtaining prior consent. See 📌 The module sent information to an external site without informing the people who are using it Active for background.

If you use this module and want your site to comply with the GDPR, you may need to take extra steps to comply with these provisions:

• Information to be provided where personal data are collected from the data subject
• Conditions for Consent

At the moment, because personal data is sent to an external site outside Europe with no provision for:

• Transfers on the basis of an adequacy decision
• Right to erasure

there seems to no way to legally use this module and at the same time comply with the GDPR.

Using this module without this being remedied may resulting substantial fines, for example, see: European supervisory authority issues €8.15m fine for international data transfer and processing failings.

@gisle not sure which personal data are involved here ? AFAICS miniorange_saml_uninstall only uses the site email, which is not associated with a physical person by default, so probably does not qualify as PII. Is there other PII being transmitted ?

I would not say that such transmission is all good without approval: it would definitely be better if the site only provided an outgoing on-screen message with a link offering to send the information rather than emitting the info automatically, but that does still does not look like PII since it is not associated with any person.

The definition of 'personal data' in GDPR (Article 4(1)) is this:

‘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;

this ('any information relating to') is a very broad defintion, and I would argue that the "site email" may be information relating to an identified or identifiable natural person, since many websites will simply use the personal email address of the site administrator for this purpose.

However, if you look at the data they actually collect, we can see from this page: https://git.drupalcode.org/project/miniorange_saml/-/blob/3.0.x/src/Util... that what they collect includes:

• $site_mail
• $admin_email
• $site_mail

as well as a lot of auxiliary data data may be used for fingerprinting and other forms of profiling because it is relating to specific personal data.

Yes, I tracked the admin_email and phone, and they are acquired when admins request support and give their email and phone expressly for the purpose of being contacted. But it does mention that it will lead to that info being used outside that specific context, so the consent exists for one purpose but is not express and informed for the other. OK.

Uninstalling the module presumably no longer requires the user to be contactable tor the purpose of receiving support, so these personal data is obviously collected for some other (non-disclosed) purpose.

I think it pretty obvious that this module violates the GDPR on mulitiple levels and belongs on the list in the issue summary.

Version 3.0.6 of the module now has this information added to the uninstall feedback form:

Upon submitting the feedback, your Admin Email, Domain Name and feedback related information will be sent to our servers so that our Drupal experts can reach out to you and provide you with proper assistance

And users may opt-out by checking the box: "Skip the feedback".

It does look like this will make the module compliant with the GDPR.

When requesting information from the data subject, article 13 requires that the following information is provided:

• the identity and the contact details of the controller and, where applicable, of the controller’s representative; the contact details of the data protection officer
• the legal basis for the processing;
• the legitimate interests pursued by the controller or by a third party;
• the recipients or categories of recipients of the personal data, if any;
• the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.
• the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;
• the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;
• the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;
• the right to lodge a complaint with a supervisory authority;
• meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.

It is obvious that none of the these requirements are satidfied.

The GDPR (Recital 32) also says: "Silence, pre-ticked boxes or inactivity should not therefore constitute consent.") I.e. the opy-out checkbox does not constitue valid consent according to the GDPR,

I would like to support @gisle. To process the data you need an opt-in, not an opt-out. And you must inform about your privacy policy. And I'm not sure where the data is processed (India is not allowed and I didn't find miniorange or xecurify.com on https://www.dataprivacyframework.gov/).

So - please - remove this feature at all. Open source software is not the place to collect privacy data.

The webform module has CDNs enabled by default to load multiple JavaScript libraries. Disabling CDN usage in general is not possible without a custom module. Installing libraries locally disables the CDN usage, but if a future update adds a new CDN based library, there is a risk, that it will be loaded from a CDN by accident. Possibly anonymous users and registered users are affected.

It also loads many YouTube thumbnails on it's help page by default. Disabling is possible, but hidden in sub tab "Advanced" under the "Config" tab. It doesn't affect anonymous users, but registered users.

While trying to opt-out on the config pages, data from third party providers is already loaded. So configuring via drush config:set or via settings.php is necessary before opening any webform route after a fresh installation.

So both violations are opt-out instead of opt-in. Opting out is hidden in nested config pages and/or need workarounds with custom modules and config overrides to reduce the risk of exposing personal data from anonymous and registered users.

GDPR related issues were closed as "won't fix" or as "works as designed" in the past, e. g. 🐛 YouTube thumbnails are embedded on help page (performance, low bandwidth, GDPR compliance) Closed: works as designed and 📌 Allow to disable (dynamic) CDN loading of libraries in general Active . So it doesn't look like the author is interested in GDPR compliance. After skimming more issues, it looks like there actually was some work already to improve GDPR compliance in certain cases. But partially compliant equals to not compliant in this case.