Disable or Anonymize IP Tracking in FieldtypeComments

[Edison]

For those who have the "opportunity" to deal with GDPR … and are implementing PW FieldtypeComments it's worth making a Privacy assessment.

When a visitor submits a comment, is going to visibly provide personal data: the commenter's name (or nickname) and email. 

Going a bit deeper, we can see that a cookie named CommentForm is created, it stores visitor's name and email, with session long duration. If you wish more details,  this cookie is entirely managed at javascript level in comments.js. Of course this cookie is very helpful as it pre-fills the comment form with commenter's information to speed up future comments submissions.

Let's make a step further and have a look to field_comments table inside the database. As you can see (PhpMyAdmin),  in addition to the commenter's name (cite) and email, FieldtypeComments is also tracking the commenter's IP address. Uh..! 

Should we ring an alarm bell ... and remove all the comments from our blog … ? Of course not ...

The simplest approach would be to make sure your privacy policy and cookie policy are taking into account all those aspects, including IP tracking, to make your visitors aware which personal data you process, why and for how long do you keep them. In light of that, it gets important to ask the commenter an explicit consent to personal data processing by a checkbox when submitting the comment form.

More specifically regarding IP tracking you may ask yourself if you really need to track the commenter's IP address. You should also get information if you-have-to-do-it because of your country laws.

If you concluded that you are not interested or obliged to track commenter's IP address, how to disable it ?

Commenter's IP address is gathered in function processInput() of CommentForm.php in FieldtypeComments module.

$comment->ip = $this->wire('session')->getIP();

Unfortunately I could not find any preset option to stop it, but (... obviously!) it is sufficient to change it to:

$comment->ip = '';

However do not forget not to modify the original FieldtypeComments in wire/modules/Fieldtype/FieldtypeComments, but copy it to site/modules/FieldtypeComments. Please refer to the initial part of this tutorial for the detailed steps to duplicate the module and make PW aware of which module version to use.

An alternative to entirely disable ip tracking could be to anonymize it. 

$comment->ip = A::anonymizeIp(wire('session')->getIP());

Through the function here below. Please note, in this function I could not test if ipv6 anonymizing works as expected.

class A {
    public static function anonymizeIp(string $ip) {
        $ipv4Mask = "255.255.255.0"; //strip last octect
        $ipv6Mask = "ffff:ffff:ffff:0000:0000:0000:0000:0000"; //strip last 80 bits
        $ipLen = strlen(inet_pton($ip));
        $ipMask = $ipLen == 4 ? $ipv4Mask : ($ipLen == 16 ? $ipv6Mask : '');
        return inet_ntop(inet_pton($ip) & inet_pton($ipMask));
    }
)

And here we are! Happy Privacy to everybody !

[netcarver]

Thanks for the tutorial, Edison.

It might be useful if the getIP() method in wire/core/sessions.php#L707 were made hookable. This would allow you to add a hook to ready.php to handle redaction, rather than having to clone the module.

 

[LostKobrakai]

I'm not sure if anonymization is actually needed for gdpr complience. It might make sense if you're looking to aggregate e.g. geo location based of of the ip, but I'd expect it's there rather for spam protection reasons. So you can block actual IPs if you're flooded with comments. Securing your system against potential attacks is a solid foundation to gather the data without any consent even under the gdpr. The more important factor for that is just how long it's justified to save the IP for that reason. 

[Edison]

Thank you @LostKobrakai you are right, IP address processing makes sense for spam protection reasons. Personally I prefer to manage IP filtering directly at server level instead of CMS level. For this purpose (and other reasons) I setup a POST Flood jail with Fail2ban on the server side, without storing IP addresses in the CMS Database. 

The problem rises when you store the IP address in the CMS database, both because you have to quantify for how long you are going to store it, and because you are directly associating IP address with user name and email. However under GDPR all of this is legitimate provided you inform the user in advance and get an explicit consent.

IP Anonymizing is just a possible option on the table, as once IP is anonymized is no longer considered "personal data" under GDPR. However since name and email are stored, an explicit consent will have to be asked anyhow.

It is important to note that another reason for comments IP tracking (and storage) is for legal purposes in the event of disputes over the content of the comments.

[Edison]

On 7/27/2019 at 8:35 AM, Hunter9 said:

Securing your system against potential attacks is a solid foundation to gather the data without any consent even under the gdpr.

Well, it depends... ?  I am not sure spam, from a pure legal standpoint, can be assimilated to a hacking attack, which may legitimate GDPR lawfulness of processing under legal obligation or legitimate interests cases. GDPR lawfulness of processing is strictly defined under article 6. Even considering broader legal interpretations (here is a good post about it), I think that the safer approach is always to get from the user a "specific purpose consent" (not to be confused with a "generic explicit consent" which would be legally weak).

You may achieve a "specific purpose consent" through a GDPR checkbox to be clicked by the user before submitting a comment, being this checkbox properly associated with a Privacy Policy which describes the data processing taking place in this specific case:

Getting a "specific purpose consent" from the user, where data processing that will take place will be properly described, matches article 6.a of GDPR. ?

Surely I am not a GDPR's fan ?, but having dealt with legal contracts for a couple of decades, I learned it's preferable to prevent than cure... ?

[LostKobrakai]

Article 6 is a good point, but its most important part is section f). 

The big problem of getting consent is that you need to deal with all the follow up responsibilities of people having the right to revoke their consent. While if you go with Art. 6 f) and you can clearly state that saving the commenters IP for a set amount of hours/days to detect spammers and prevent their acting does not outweight "the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child." you can just add a paragraph to your privacy documents, which your users can read, but be fine otherwise. You should only need to document the above and how you weight in the interests of the company vs the ones of the persons you save the IPs of. This is also a place where a good lawyer can be of great help.

For the given case: IP addresses of people in a private (not corporate) contexts are rarely static. So to get to the real person behind the IP after certain timeframes you'd need to go to an ISP and ask them which connection had this IP at a give time and present a good reason for why you're asking. Also you might not even store the IP super long as more than 7/14/30 days is not really needed to be able to act on spam. On the other hand a proper spam attack can be a real risk to the business depending on the website. To the worst extend the website might make users buy stuff from scammers and therefore harm other users of your website. So I thinks there are quite a few arguments to weight against, which might resolve in a case where consent can be left out.

Please keep in mind that the above is only from my own research and if you want to be sure about stuff talk to a lawyer. 

[Edison]

Yeah, on the net there are several references to the application of "legitimate interest" as described in article 6.f, which of course in certain cases it makes great sense. For example apache log files are tracking ip addresses and can be properly used to protect from attacks provided their storage is limited in time.

Sometimes on the web the "legitimate interest" is presented as a sort of preferred way, because of course it greatly simplifies, however, to my personal point of view, there are some drawbacks to consider.

In certain cases appealing to article 6.f may sound quite weak from a legal stand point. The part of the paragraph which states "except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data" implies that the data controller is taking full liability these circumstances are not taking place. If any user is able (and willing) to demonstrate somehow its interests have been damaged, the company who has chosen article 6.f way can be seriously hurt in a court, as they have chosen to operate data processing without any consent from the user. But... as a lawyer was used to tell me: "it's a business decision!" ?

More specifically, coming back to PW Comments, we have not to forget ip addresses are stored in the database TOGETHER with the user email, and possibly the user name, so THE REAL USER CAN BE IDENTIFIED. ?This goes beyond the "legitimate interest" case described by 6.f.

But definitively these are matters for lawyers ! ?

[Melvin022]

On 7/14/2019 at 6:00 PM, Edison said:

For those who have the "opportunity" to deal with GDPR … and are implementing PW FieldtypeComments it's worth making a Privacy assessment.

When a visitor submits a comment, is going to visibly provide personal data: the commenter's name (or nickname) and email. 

Going a bit deeper, we can see that a cookie named CommentForm is created, it stores visitor's name and email, with session long duration. If you wish more details,  this cookie is entirely managed at javascript level in comments.js. Of course this cookie is very helpful as it pre-fills the comment form with commenter's information to speed up future comments submissions.

Let's make a step further and have a look to field_comments table inside the database. As you can see (PhpMyAdmin),  in addition to the commenter's name (cite) and email, FieldtypeComments is also tracking the commenter's IP address. Uh..! 

Should we ring an alarm bell ... and remove all the comments from our blog … ? Of course not ...

The simplest approach would be to make sure your privacy policy and cookie policy are taking into account all those aspects, including IP tracking, to make your visitors aware which personal data you process, why and for how long do you keep them. In light of that, it gets important to ask the commenter an explicit consent to personal data processing by a checkbox when submitting the comment form.

More specifically regarding IP tracking you may ask yourself if you really need to track the www.mycfavisit.com commenter's IP address. You should also get information if you-have-to-do-it because of your country laws.

If you concluded that you are not interested or obliged to track commenter's IP address, how to disable it ?

Commenter's IP address is gathered in function processInput() of CommentForm.php in FieldtypeComments module.

$comment->ip = $this->wire('session')->getIP();

Unfortunately I could not find any preset option to stop it, but (... obviously!) it is sufficient to change it to:

$comment->ip = '';

However do not forget not to modify the original FieldtypeComments in wire/modules/Fieldtype/FieldtypeComments, but copy it to site/modules/FieldtypeComments. Please refer to the initial part of this tutorial for the detailed steps to duplicate the module and make PW aware of which module version to use.

An alternative to entirely disable ip tracking could be to anonymize it. 

$comment->ip = A::anonymizeIp(wire('session')->getIP());

Through the function here below. Please note, in this function I could not test if ipv6 anonymizing works as expected.

class A {
    public static function anonymizeIp(string $ip) {
        $ipv4Mask = "255.255.255.0"; //strip last octect
        $ipv6Mask = "ffff:ffff:ffff:0000:0000:0000:0000:0000"; //strip last 80 bits
        $ipLen = strlen(inet_pton($ip));
        $ipMask = $ipLen == 4 ? $ipv4Mask : ($ipLen == 16 ? $ipv6Mask : '');
        return inet_ntop(inet_pton($ip) & inet_pton($ipMask));
    }
)

And here we are! Happy Privacy to everybody !

It might make sense if you're looking to aggregate e.g. geo location based of of the ip, but I'd expect it's there rather for spam protection reasons. So you can block actual IPs if you're flooded with comments. Securing your system against potential attacks is a solid foundation to gather the data without any consent even under the gdpr. The more important factor for that is just how long it's justified to save the IP for that reason.