back to phpList.org

phpList GDPR compliance : defects and improvements suggestions

gdpr
Tags: #<Tag:0x00007f92617bad68>

#1

Hi,
Since I installed and setup v3.3.3, and after reading some of this posts, i’ve identified a few ways of improvement for a better GDPR compliance. This are free suggestions, opened to discussion!

So here is the short list:

1. Blacklisted users maintained in database when they are removed from BackOffice

Description

  • When a user is member of the blacklist, its removal from the backoffice (whatever the method is used) does not allow to really erase it from database:
    . Relevant tables :
    -> phplist_user_blacklist
    -> phplist_user_blacklist_data
  • However, this blacklisted and removed users remain completely invisibles to the backoffice administrators
  • This question was discussed here but the legal department that i consulted didn’t have the same reading of Article 21

Proposal

  • Keeping this method as a default procedure allowing to prevent untowards new invites
  • Add a dedicated interface allowing to answer GDPR requirements:
    . searching, listing and export personal data of this “ghost-blacklisted” users
    . really wiping out users’ data on demand

2. No built-in unsubscribe feature with deletion of personal data

Description

  • When a user ask to stop receiving messages, he doesn’t have means to truely wipe-out his data

Proposal

  • Add an option (unchecked and not recommended by default) to the unsubscribe form allowing the users to withdraw without leaving data, including into the database (GDPR requirements)

3. Checkbox for consent to terms of service/privacy policy not registrable when users subscribe via the Invite plugin

Description

  • The enrolment/re-enrolment campaigns sended by the Invite plugin (integrated to phpList into the purpose of consent renewal) do not allow the validation of the consent attribute (itself added to conform to GDPR) upon confirmation

Proposal

  • Insert an attribute validation/update step upon invite confirmation

4. No scheduled task to delete subscribers who signed up and have not confirmed their subscription

Description

  • The backoffice function “To delete subscribers who signed up and have not confirmed their subscription” does not have a scheduled task easily activable

Proposal

  • Add a CRON task that should be enabled and configured (time limit) into the config.php file

5. No GDPR-oriented parameters

Description

  • The settings configuration page does not have some fields that might be useful

Proposal

  • Add a few attributes:
    . Privacy policy / Terms and conditions
    . Contact and DPO’s name
  • Transcribe these attributes as placeholders

6. No API allowing to audit personal data

Description

  • phpList does not contain an API allowing an external tool to list personal data

Proposal

  • Develop a dedicated API

7. “Remove subscriber from blacklist” button down

Description

  • The button appearing in “search for the subscriber -> view their profile -> click history -> click subscription” does not seem to work
  • enabling the details page button to overcome the defect:
    . define('UNBLACKLIST_IN_PROFILE', 1);

Proposal

  • Fix this bug?

#2

My thoughts on #1 are fairly well documented already, but I want to add that deleting a blacklisted user from the database does not delete from their system any mail you have sent to them. They can then use your message to them in a legal action where you would have no data with which to defend your reason for sending said message. So, again, I think actually deleting records is a really bad idea (and I do not believe that leaving blacklisted individuals open to being contacted again is in the spirit of the GDPR, regardless of varying readings of the text).

#2 – Agree mostly but I think the option should be checked by default. I can’t imagine a circumstance where I would want my data to be retained if I’m trying to part ways with a sender.

#3 – No comment, I do not use the Invite plugin.

#4 – I do not see this as a GDPR issue, but it is a data issue. If a subscription is not confirmed, it does not necessarily represent a real person with privacy rights. It could be garbage data entered by a spammer. It could also represent a real person who has no idea their information has been entered by a third party (for whatever reason – mischief, malice, etc.). We can’t know, and messages should never be sent to an unconfirmed address. The longer the address goes unconfirmed, the more likely it is worthless (regardless of who entered it), so it would still be good to have automated removal after a configurable time. I have no personal experience with unconfirmed addresses, though, so I don’t know what phpList offers now.

#5 – When you say “decline these attributes as placeholders” I assume you mean they should not be usable in a message. I would disagree for the second suggestion (contact/DPO name), that seems like it might be useful.

#6 - Seems like a good to-do item for the phpList 4 API.

#7 - no comment, no experience with this


#3

#1 - Yes, very varying readings of the text :thinking:

#4 - Whether any message is send or not, it’s personnal data retained, and it should have a length of time to be stored. That was the point.

#5 - I meant “transcribe this attributes as placeholders” (sorry for this translation issue :confused:). I think both of this attributs should be usefull as placeholders.


#4

#4 - It’s not personal if it’s not about a person, and we can’t know if it’s about a person if it’s not confirmed. If somebody subscribes with the address joe.smith@neighborwifi.com it only looks like personal data but it is not, because there is no person with that address (that’s one of my domains, so I can say this with 100% certainty). It’s just garbage data. My point is that until an address is confirmed as actually being connected to a real person (and one in an EU-relevant context), that address is only data, not GDPR-relevant personal data. I think we want the same thing – automatic removal – but for different reasons. It only matters to the extent that GDPR-related fixes should be focused on actual GDPR issues.