As has been noted, it would be desirable for phpList to comply with GDPR’s article 25 principles of data protection by design and by default.
(there are a couple of older threads regarding the GDPR, and a link to a meta issue tracking phpList GDPR compliance)
Data protection by design and by default primarily concerns how the software itself functions, not how the data controller chooses to set up and use the software.
Let’s assume a very simple scenario: we only want to collect people’s email addresses, and we only want to use those email addresses to administrate a mailing list and send out newsletters.
However - unless I’ve missed out on something - this is phpList’s default behaviour:
- It automatically collects and saves a bunch of information about subscribers who sign up, like their
- IP address
- Brand and model of device used (like a specific brand and model of phone for example)
- Operating system and version used on the device
- Web browser engine used on the device
- It also automatically collects and saves information on:
- Date and time each time a subscriber opens an email they have received
- Date and time each time a subscriber clicks a link in an email, and which link
There also seems to be a phpList logo automatically inserted at the bottom of emails, with a specially formatted link to phplist.com which begs the question if clicking this link allows phpList Ltd to log personal data on subscribers. Remember, even something as ordinary as an IP address is considered personal data.
In my view, to comply with data protection principles, the above behaviour should probably be turned off by default. Which is to say, the phpList admin should have to actively switch on the data collection described, since there must be a legal justification for each piece of personal data collected. In the simple scenario described above, I don’t really see how there would be a need to collect and save all that extraneous data. Tracking open rates etc. on an individual level could of course be valid if there is consent, but by default we probably shouldn’t assume all administrators are going to ask for, not to mention obtain, such consent from every single subscriber.
There are other aspects that could be improved as well. For example, how about automatically purging data about unconfirmed subscribers after 1 or 2 weeks. If a confirmation email gets lost in a spam folder, it’s unlikely the person is going to dig up that email after this much time has passed. One may also consider adding a feature where clicking a confirmation link after the data has been purged from phpList, would automatically redirect to the list’s subscribe page. However, since purging unconfirmed subscribers can be done manually the need for such a feature isn’t as pressing. For the other points noted above though, I haven’t found a way in phpList’s administrator interface to disable the data collection.
I hope this comes across as constructive, since I really appreciate and with this would like to help improve the software.