This issue is in regards to the The EU General Data Protection Regulation (GDPR), which will come into effect on 25 May 2018 (that's 11 days from now).
I'm not a lawyer, but I've been carefully reading over the publicly available information I could find about it, and trying to make sense of it all, to figure out exactly what measures should be implemented, both here for CIDRAM, and for other, related projects (e.g., phpMussel), in order to mitigate any legal risks as much as possible.
In reference to:
Of particular note:
What constitutes personal data?
Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address.
I'm not entirely sure what effect this would have on basic logging functionality from a legal perspective (e.g., logging blocked IP addresses, and with an IP address being considered "personal data" in most contexts according to GDPR), but due to that logging is an essential part of the package (so, not practical to remove at all; forcibly disabling or removing it would make no sense, I think), and considering that it requires modifying various configuration directives (e.g., specifying which filenames to use for logging block events) in order to work properly anyway, my current thought, is to leave it be and not change anything about it at all, but to add some information to the documentation (I would propose, in the form of a new FAQ entry, advising users that they are responsible for deciding what to enable in the package and what to leave disabled, advising users that we aren't lawyers, and that they should seek their own legal advice about these matters if they need help in making these decisions, and that certain features of the packages might be incompatible with GDPR or similar such laws).
If anyone else had ideas about this though (possibly other suggestions, or opinions about what I've suggested above), I would be happy to hear those ideas.
Next, in reference to:
Currently, both CIDRAM and phpMussel leverage some Google Webfonts for some of their themes (including the default theme). A configuration directive (disable_webfonts) is already supplied in both packages, allowing package users to disable webfonts if they so choose. However, this directive is set to false by default. As using Google Webfonts without explicit consent from the end-user may cause non-compliance with GDPR, I propose that the default value of this directive should be changed to true, in order to mitigate any legal risk for package users (thus disabling webfonts by default). Additionally, the directive documentation should cross-reference to the newly added FAQ entry. (It's on the to-do list currently to be able to host WOFF files locally within installations at some point, but as this feature hasn't yet been implemented, simply changing the default value of an existing directive might be the simpler, more expedient solution for now).
Next: Use of reCAPTCHA in CIDRAM.
Official statement from Google in regards to GDPR compliance:
Our commitment to GDPR
We are working hard to prepare for the EU’s General Data Protection Regulation (GDPR). Keeping users’ information safe and secure is among our highest priorities at Google. Over the years, we have spent a lot of time working closely with Data Protection Authorities in Europe, and we have already implemented strong privacy protections that reflect their guidance. We are committed to complying with the new legislation and will collaborate with partners throughout this process.
..Which is great and all, and great to hear that collected data is apparently secure, but doesn't really address the problem of user consent.
One possible solution, is to force that a predefined "privacy agreement" be presented to users, before reCAPTCHA is loaded, in order to gain their explicit consent. I don't think this is really practical though, due to possible language barriers, possible interference with normal logging routines, general inconvenience for users as they would be being forced to read a lot of information, just to be allowed to prove that they are human (e.g., to be given the opportunity to complete the reCAPTCHA instance). Alternatively, a similar approach could be taken as per suggested above with logging and webfonts: Have the configuration directives related to reCAPTCHA be crossed-referenced with the newly added FAQ entry, to make it clear that there may be possible legal compliance issues, and that websites serving EU users might want to leave it disabled. Going on this idea, we wouldn't need to implement any changes to the codebase itself, seeing as reCAPTCHA requires API keys in order to work (thus meaning that it is disabled by default, until the package user enters some API keys into the configuration).
Worth noting too: Current implementation of the "invisible" reCAPTCHA would definitely be non-compliant, due to that CIDRAM handles everything automatically, meaning there'd be a high chance that the end-user wouldn't notice anything anyway (thus eliminating the possibility of gaining meaningful consent). At the very least, websites targeting EU users should probably revert to the older, more primitive "V2" reCAPTCHA, due to that it isn't automatic (though disabling reCAPTCHA entirely would still be preferable, from the perspective of mitigating legal risks).
There are also some provisions in GDPR about websites based in member countries not being allowed to block IPs from other member countries (which.. could be problematic for website owners, to say the least), but shouldn't be any problem from the perspective of package maintainers, due to the basic warranty disclaimer as per the GNU/GPLv2 license and such ("This script is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE" ...), and that a maintainer is not the same thing as the entity which installs or operates the package (which would be responsible themselves for however they choose to install and operate the package). It's also mentioned in our FAQ already that individual website owners are responsible for what they choose to block and not block:
I've been blocked by CIDRAM from a website that I want to visit! Please help!
CIDRAM provides a means for website owners to block undesirable traffic, but it's the responsibility of website owners to decide for themselves how they want to use CIDRAM. In case of the false positives relating to the signature files normally included with CIDRAM, corrections can be made, but in regards to being unblocked from specific websites, you'll need to take that up with the owners of the websites in question. In cases where corrections are made, at the very least, they'll need to update their signature files and/or installation, and in other cases (such as, for example, where they've modified their installation, created their own custom signatures, etc), the responsibility to solve your problem is entirely theirs, and is entirely outside our control.
In summary, what I've proposed above:
- Adding a new FAQ entry to the documentation to address possible legal risks, advising users to seek their own legal advice if necessary, and to reiterate that we aren't lawyers, nor legally responsible for their choices.
- Cross-referencing directives related to possibly affected features to this newly added FAQ entry.
- Changing the default value of
disable_webfonts to true.
Thoughts, ideas, opinions, etc, are invited. Whatever we decide though, I'll want to get started ASAP, in order to try to get everything finished before May 25th (changes proposed thus far are pretty small anyway, so, I could probably get it all done in a day or so, assuming we don't decide on something much more complicated).
Proposal Implemented Documentation QA
51 Nov 21, 2022
169 Jan 3, 2023
27 Nov 18, 2022
0 May 5, 2022
1.1k Jan 3, 2023
7.3k Jan 6, 2023
216 Oct 18, 2022
2 Aug 7, 2022
2 Mar 24, 2022
20 Jun 23, 2022
3.2k Jan 5, 2023
1.2k Jan 7, 2023
22 Nov 7, 2022
3.5k Jan 7, 2023
1 Aug 14, 2022
22 Nov 4, 2022
1 Jan 15, 2022
8 Oct 10, 2022
371 Dec 17, 2022