GDPR: Data Protection by Design and by Default

đź’» Development
1

Hi there!

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.

1 Like
2

Thanks Arman, that’s very interesting.

Yes, phpList is 20 years old, and I agree it can do with an update to bring it into the current way of working.

Yes, that’s correct. And interestingly enough, phpList does not use this information at all. The main reason to record it was to be able to diagnose rendering issue people might bump into, but that’s never been necessary. Recording IP addresses is actually quite a hard thing to get rid of. Even if phpList doesn’t record it, it will still be in the server log files.

This can be switched off with this config setting: phplist3/public_html/lists/config/config_extended.php at main · phpList/phplist3 · GitHub

Yes, but that’s kind of the whole purpose of using phpList, it helps to identify the engagement of your subscribers. For example, you can stop sending to subscribers who haven’t opened your campaigns for some time. That’s useful information.

The image can be switched off with phplist3/public_html/lists/config/config_extended.php at main · phpList/phplist3 · GitHub
but even then, yes, there will be a link and yes, it will record the IP address.

Well, I think this can be handled by having terms and conditions on the subscribe page. Basically, “if you subscribe to our newsletter, you consent to us using your data”. That’s this one: https://mantis.phplist.org/view.php?id=19033

That would only work when subscribers sign up with the phpList subscribe pages. I suspect that most installations use the import functions, in which case phpList has no idea about consent.

I agree that some work can be done to bring phpList more in line with the current ways of handling privacy and helping administrators to do the correct thing. Another nice feature would be for example the ability to download all your data, or at least allow an administrator to build a zip when requested.

I must say that in the light of applications out there, phpList is not very intrusive. Most options can be switched off and configured. For us to have a little bit of an idea of usage of phpList helps to motivate to keep developing it.

But it’s true, “By Design and Default” requires settings to be explicitly enabled, instead of disabled and that can do with some changes.

Thanks for raising this. If you have any PRs to address this, we’d be grateful.

3

Thank you for your reply.

I appreciate that phpList has a venerable heritage. :smiley:

Key to understanding how to follow EU privacy/data protection law is understanding the purposes for which personal data is processed, and in each case determining which processing is genuinely necessary to achieve each purpose.

So if phpList needs to store IP addresses to function, that’s basically fine. But just because IP addresses are kept in server logs (for its own separate purpose), that doesn’t make it okay for phpList to keep IP addresses as well if there is no reason for phpList to do so. As with the rest of that information (device, OS, etc.), if there isn’t really a proper purpose for collecting it, then it shouldn’t be collected. And if there is a reason to collect it, it shouldn’t be kept for longer than is necessary to fulfil the purpose for which it was collected in the first place.

This follows from the GDPR principles of data minimisation and storage limitation, respectively, in articles 5 c) and 5 e). (And as a side note, when it comes to collecting information from the user’s device, the ePrivacy Directive actually comes into play)

With regards to consent, there is a legal requirement that the user is given a genuine choice in relation to each specific purpose consent is used for. There is a prohibition on bundling different purposes into one consent; there must be granularity related to purposes. This is explained in the European Data Protection Board’s Guidelines on consent, for example paras 55-58 (page 13-14).

As for metrics that track engagement, I appreciate this is useful to many organisations running phpList.
However, keeping in mind consent and purposes, there must then be a separate choice for consenting to behavioural tracking. The purpose of signing up to a mailing list is typically to receive marketing or information from an organisation. You basically only need to collect an email address to achieve this. The organisation’s data collection enabling analysis of subscriber behaviour is a different purpose to merely maintaining the list and sending out the emails. Furthermore, it should be possible to withdraw consent without detriment. It follows that consenting for the purpose of receiving marketing/information should be possible without having to also accept data collection which isn’t necessary for receiving the marketing/information.

When lists are imported into phpList, then the data controller has a responsibility to ensure consent was obtained and that this can be proven, whether by having this data in phpList or keeping track of it in a different manner.

As for a subscriber clicking the phpList logo/link, it’s again a matter of purposes and what data may be collected by the company phpList Ldt. An IP address in a server log is one thing, but if phpList Ldt was collecting device information on subscribers who happen to click the logo it would be another matter.

I’m not a programmer, so I can’t contribute with PRs, what I can offer at the moment is merely some insight into EU data protection law and how it relates to phpList. :slightly_smiling_face:

Believe me, I get that this might not be the most fun “contribution” to receive, and that phpList is probably way less intrusive than most other options out there!

Another principle of the GDPR is the accountability principle. Data controllers must be able to show how they comply with the principles of the GDPR. As individuals, marketers and supervisory authorities wake up, demand for newsletter software you can use in a compliant manner will only grow. By addressing these issues you could truly market phpList as a fully privacy conscious mailing list solution.

Maybe the easiest first step to take would be adding an interface toggle for that subscriber data collection on sign-up, and having it be off by default at least in completely new phpList installations.

4

Also, a quick question:

This can be switched off with this config setting: https://github.com/phpList/phplist3/blob/master/public_html/lists/config/config_extended.php#L236

I tried to edit the config.extended.php file a couple of different ways:

$userhistory_systeminfo = array(
//     'HTTP_USER_AGENT',
//     'HTTP_REFERER',
//     'REMOTE_ADDR',
);

and

// $userhistory_systeminfo = array(
//     'HTTP_USER_AGENT',
//     'HTTP_REFERER',
//     'REMOTE_ADDR',
// );

Neither way appears to make any difference, upon trying to add a new subscriber the information is collected anyway. Is there anything in particular I need to consider to make the change effective? Apologies if this strays into user support and there’s a better place for the question…

5

To make any use of this code, it MUST in the config.php file, which is the only file phpList uses.
config-extended.php is there to show all the options that can be used, but it must be copied into config.php

6

To make any use of this code, it MUST in the config.php file, which is the only file phpList uses.
config-extended.php is there to show all the options that can be used, but it must be copied into config.php

Thank you! This worked.

Just a couple of dead links I ran into during this:
In the config.php file there is a link to system:config [phpList Resources] which does not appear to be working for me.
Searching for a way to donate to encourage development (:grinning:), I found Contribute to phplist : phpList where there is a link to donate, but the link appears to be dead.

7

You will want to use https://resources.phplist.com/system/config instead

To contribute, https://www.phplist.org is the place.

As for the GDPR issues you’ve raised. I’ve taken notice, and will process in due time. If you have specific issues you want resolved, feel free to open an issue on Github and it can be handled there.

1 Like