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);
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.
#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 ). I think both of this attributs should be usefull as placeholders.
#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.
#8 (this is a new one) the unique id associated with a subscriber can be used by anyone to access that person’s preferences page. Any personal information that person has entered can be viewed and edited. The lists a person is subscribed to is personal information if the lists are sensitive - political, religious, health etc
Just forwarding an email passes the unique id…
Unsubscribing needs to be a one click operation but viewing which lists a person has signed up for and any fields associated with an unique id or an email address should require access to the email account in a two step process. I think a second unique plus a timestamp would be sufficient
@thedayse#8 Good point, thanks for sharing. Would it not be possible to simply obfuscate the ID during the foarding process (e.g. when the Forward button is used)?
It’s true that many people use forwarding from their browser rather than the built-in Forward link. However for gdpr purposes, in those cases the person has chosen to share their email and the contained ID, and I assume that the responsibility for their protection lays with them, and not with the phpList administrator.
I don’t think obfuscating the id is enough. I haven’t looked at how the forward link works as I never include it, as forwards from the system are more likely to get spam flagged. I assume people prefer to forward from their mail client rather than from an embedded link. The links I include are preferences and unsubscribe.
If I forward an email I know that I’m sharing my email address and the visible content of the email. I don’t know that I’m sharing a hidden token that can be used to view and edit other data stored in the phplist system that sent me the email. I guess a warning in each message warning against forwarding the message is something admins can do but I’d rather not. In general we want people to forward stuff. More of an issue is that any external scripts and images that a subscription page loads also see the uniqueid because it is a get method variable.
Before GDPR, administrators could have several extra fields for a subscriber, that only the admin could access, so it was secure enough. Now the subscriber must be able to see all their data which in turn means having a subscribe page with all fields on it, and that page needs some security.
). I think both of this attributs should be usefull as placeholders.