back to

Using phpList for compliance with the GDPR: manual chapter feedback and discussion

Tags: #<Tag:0x00007f2f7c83a6f0>


This is a new chapter in the phpList manual:

This thread is for feedback on this chapter.


@samtuke Very good and helpful, thanks! Here are a few comments, but I am not a lawyer so no comment to the difficult task what is and what is not mandatory for compliance with GDPR:

  • Is it really now routinely necessary to have a check box where subscribers confirm on the subscribe page that there age is above 16 when the topic of the mailing list is not all related to age or critical in this sense?
  • there is one word “which” too much (Chapter Consent line 11)
  • so no more unsuscribed clients on the blacklist in order to avoid accidental inclusion in the next campaign or to avoid bounces?
  • “use the Data Export feature…” for “Right of Access” but in this general subscriber info and history file there may be/is a lot (!) not really self explanatory stuff. And the GDPR demands easy to understand explanation and presentation of data. Do you think subscribers should access this download automatically and by themselfs, respectively. I thought the stored data on the preference page are already enough and regarded as “complete”?
  • what about the stored IP address in this file?

So what is your recommendation (not in a strict legal sense of course) can be fixed concerning GDPR by offering the necessary access (links) to the related pages (mostly preferences) to subscribers and where to tell them to contact the administrator to achieve what they want (regarding the above problem of complicated history files with IPs in it)?

However, very good and useful detailed recommendations.

GDPR re-permission campaigns ( invite Plugin)

I’m not sure, but my reading is that it’s safer to include it if content is not meant for children.

Please can you quote the context? I can’t see this on the Manual page for GDPR.

There is an exception for this case, see this post.

I’m not sure. The safest option seems to be to export everything that we have, and necessarily that will not always be easy to digest (e.g. should IP addresses include an explanation of the technology and meaning behind them?). So long as requests for access are met in a timely manner then the subscriber does not need direct access to export them themselves. Clearly that would be more convenient, but also raises potential security questions about the identity of the subscriber (e.g. “appropriate security measures in relation to the sensitivity of the data”).

What about them? :slight_smile:

My understanding is that what you described, in combination with consistent use of double opt-in and adequate server security, covers the bases as far as GDPR compliance is concerned.


@samtuke Thanks for your comprehensive answer! I have to think about details.

Here is the double “which” (careful I am not a native speaker) :wink::

The subscribe page or form which into which they initially add their details


@samtuke Ok, one comment to the first point. You wrote:

I’m not sure, but my reading is that it’s safer to include it if content is not meant for children.

Yes exactly, if the content is not dealing with adult stuff or violence but as in my case boring technical/scientific matters any danger to children can be ruled out. Thus IMHO there is no need to carry out an age check.

Therefore the proposed paragraph in the manual:

If children are not your target audience, add a required attribute to your subscribe pages and sign up forms for age confirmation

I find a little misleading. Maybe better " If the content is somehow related to adult content, violence or other age sensitive matter, add …"


Some quotes from the GDPR itself :

Activities addressed specifically to children shall receive specific attention;

Such specific protection should, in particular, apply to the use of personal data of children for the purposes of marketing or creating personality or user profiles and the collection of personal data with regard to children when using services offered directly to a child.

Some advice from the most popular GDPR resource:

A special item in this regard is consent for children and adolescents in relation to information company services. There is an additional consent or agreement requirement from those with parental rights for those who are under the age of 16. The age limit is subject to an escape clause. Member States can reduce this in their national law to 13 years of age. Should the service offering not explicitly be directed to children, it is freed of this rule. This does not apply, however, to offers which are open to both children and adults.

From all this I agree with you that it seems the current manual wording is misleading, and shall update it. Thanks :+1:


@samtuke Ok, my perspective seems to be too narrow. There is a lot of marketing to youngster going on which does not make it easer to find the right words…