GDPR with 3.0.11

Dear @burnuser,

I’m very thank you to your immediate feedback and suggestion enough worth to be adopted!

Not only to allow individual selections, but also – and not less important – to inform users of each setting and its use direct in the interface!

I agree this is very important because site owners should decide their privacy policy and describe it on their site. So I’ll try to consider some example use cases based on your recommendation.

2.) Set a declared limit of time for Log rotation is very important for GDPR, but … I can not find such an option.

Definitely, we need it.

I’ll keep up improving related to this topic until the day.
Thanks again!

@burnuser and all,

I released the version 3.0.12 to enhance the privacy related features. Here are the summaries:

1. Anonymize IP address and restrict 3rd party APIs: In version 3.0.11, it was named as “Privacy friendly” which was not clear title.
2. Record “IP address cache”: Disabled by default.
3. Record “Logs”: Disabled by default.
4. Expiration time [sec] for “Logs”: 1 week by default.
5. Record “Statistics”: Enabled by default because it does not record any personal data.
6. Remove all settings and records at uninstallation: Enabled by default.
7. The title of header: Still “Privacy and record settings“.

If you have any further suggestions, please let me know.

Thanks!

Thank You for the changes!

But in my opinion, there are 2 points left:

a) Like stated before (and in GDPR Recital 50 https://gdpr-info.eu/recitals/no-50/): “Indicating possible criminal acts or threats to public security by the controller and transmitting the relevant personal data in individual cases or in several cases relating to the same criminal act or threats to public security to a competent authority should be regarded as being in the legitimate interest pursued by the controller.”

For this, we need the full IP (no anonymization!) from intrusion log.
Of course only for this usage. So encryption and restriction to 3rd party APIs is one point. And Anonymization is a separate one, which should/must be a separate option. (Or taking actions against criminals is not possible!)

b) Expiration time for Logs is important, 1 week by default is good, but … adjustment in seconds is not good. (No one can imagine days in seconds.)
Days would be a good time unit …

Hi @burnuser,

Thank you for your opinion and suggestion!

a) Current design is based on my thought that the main purpose of anonymization is for personal data breach including against the 3rd parties by any chance. I think only the encryption in log is not enough in case of data breach. In the log alone, individual would not be identified even in the unlikely case that anonymized IP address was decrypted. Conversely, with both of this plugin’s log and the server’s log, the criminal would be identifiable. (The time stamp of this plugin’s log is the same as the server’s.)

Or is transmitting log including anonymized IP addresses to a competent authority illegal? My understandings is that legitimate interest do not require the complete identifiable data in log alone.

Any discussion?

b) Yep, I completely agree! I just skipped user friendly programming. I though that the pretty format like “1 week”, “2 weeks” or “7 days” was a bit complicated. But simply “days” is enough for the unit. I’ll improve it in the future!

Thanks.

OK, discussion ??

In case of anonymization we have two points:
1.) More than one user has regular access to log-data
2.) Data breach by a successful WordPress hacker attack
All of them have access to decrypted log-data.

In both cases anonymization is helpful, but the risk is – on regular websites – not very high. (IP addresses without any other useful data are not really valuable for hackers or bad people with user access.)

On the other hand, a synchronized evaluation of your IP log and server log could be a problem in the sense of a legally valid proof. (Must also proof that the time is really the same. Also technical problems in on of the two logging activities could cause a proofing problem.) And you must combine two different GDPR processing activities (and declare this in advance).

I think every GDPR controller has to decide on his own and be responsible for what is more important to him. And so I really think you should make the anonymization of logs a separate option, with anonymization ON as default. (And with pros and cons in tooltip, if you like.) And your users can decide.

By the way, the encryption is very GDPR-valuable for WordPress backup on a remote service like Google Drive or others. (You should emphasize that ??

Dear @burnuser,

First of all, I’d appreciate your discussion about this topic with me!
I’m very happy because I have been struggling so long time to find any good solutions to fit my plugin with GDPR. I was alone as a personal developer (in Japan!).

After I read your opinion, I noticed that I have to consider the relation (or role?) between not only data subject and processor but also data controller.

At first, I thought that data processor should not have “Single Failure Point” in order to meet “Privacy by design” policy. For example, if my plugin had only encryption capability, it would not meet “Privacy by design” policy. That’s the reason why I think I should implement both encryption and anonymization dually.

So to speak, it’s like a so to speak “two factor authentication”. It’s better than a single authentication. But it’s just better, not required!

I’m now becoming to agree with your opinion like:

I think every GDPR controller has to decide on his own and be responsible for what is more important to him.

and also:

And you must combine two different GDPR processing activities (and declare this in advance).

(And with pros and cons in tooltip, if you like.) And your users can decide.

Yeah, actually I should do that to tell the user what they mean, but the description is a bit difficult for me because English is not my native language!

Anyway, I’ll keep thinking about this topic.
Thanks again!

P.S. The time stamp in this plugin’s log is based on the server’s environment value $_SERVER[‘REQUEST_TIME’] which seems to the same time stamp in the server’s log. But I can’t make a proof on every type of servers ??

Dear tokkonopapa,

first of all I have to say that I appreciate the discussion with you too ??

By the way, English is also not my native language. Greetings from Austria (Europe) to Japan! (Nice transcontinental conversation!)

Thank Your for Your great plugin which is very valuable for WordPress security!

And about your responsibility:
a) Yes, You are right, encryption AND anonymization should both part of the plugin security according to “privacy by design”. (Good work!)
And activating both of them – and 7 days log expiration time – by default means “privacy by default”. Everything is OK.
And there … Your responsibility ends.
b) How to use the plugin and its collected data (anonymized IPs or full IPs) and accepting the associated risks – or not – depends on the special situation, installation and use of the secured website .. and the responsible controller.

So, You are on the right way!