Timeline for Is displaying email addresses in an application log file allowed under GDPR?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 28, 2019 at 19:49 | comment | added | schroeder♦ | I'm not equating pseudonymous with anonymous. My entire point is that you cannot swap email with userID and get pseudonymisation. If you want to achieve pseudonymisation, then that's a separate process, which does not depend on userID and can still be done with the email address. It's the process that gets you pseudonymisation. Your answer glosses over this rather large aspect of GDPR. To focus on userID is to go astray before you start. | |
| Jan 28, 2019 at 16:57 | comment | added | reed | @schroeder, so pseudonymous data is useful because it can help you with some tasks. For example, it allows you to share the data with somebody else (for reports, statistics, support, etc.), without giving them unnecessary (and excessive) personal data. So it should be clear why using IDs in logs is better than emails. IDs contain less information (ID123 vs name.surname@domain) and are generally harder to link to anything unless you also have access to other information. And I never said an ID is enough for anything, I don't know where you are reading that. | |
| Jan 28, 2019 at 16:57 | comment | added | reed | @schroeder, there must be a misunderstanding about pseudonymity and personal data. Pseudonymization means that a parameter like "John Doe" (name) is replaced with ID123 (ID), and the correlation between name and ID is kept separate (by technical and organizational means). Pseudonymous data is always personal data, because it can be used to identify a person. Pseudonymous doesn't mean anonymous. Anonymous data would be something like: "Most people named John are overweight". No way to identify a person from that. | |
| Jan 28, 2019 at 16:46 | comment | added | schroeder♦ | @Darkwing I get all that, but the answer, as written, does not include any of these subtleties which makes it incorrect advice. | |
| Jan 28, 2019 at 16:05 | comment | added | Frank Hopkins | @schroeder association from ID to PII, e.g from some database. | |
| Jan 28, 2019 at 16:04 | comment | added | Frank Hopkins | @schroeder and here you spelled out the difference: the email address is PII, the userID can be PII. It's quite context dependent especially with regard to using appropriate measures to secure user information. The other big issues is that you are typically required to delete PII on request or when a contract ends. Meaning, if you have emails in the logs you technically would need to delete all entries that contain the mail in your log archive (unless the logs are completely deleted within the necessary time frame anyway). If you have IDs in the logs, it might suffice to delete the [cont] | |
| Jan 28, 2019 at 15:18 | comment | added | schroeder♦ | "user ID ... which has a higher level of pseudonymization" This is false. You are claiming that the ID is sufficient for this use case. It is not. Even if the userID needs to be correlated with other data, it can stiil be PII. | |
| Jan 28, 2019 at 13:39 | comment | added | reed | @schroeder, my answer never suggests that an ID is sufficient for anything. It just says that in this specific case (supposedly useless emails in logs) IDs are probably going to be a better option to achieve security and privacy by design, and minimizing the risks. IDs help with pseudonymization in this case because the "additional information" needed to identify the person will not be in the log itself, but somewhere else (probably a database). Email addresses generally provide much less pseudonymity. I did not make any assumptions on anything else. | |
| Jan 28, 2019 at 12:43 | comment | added | schroeder♦ | Please read the comments and the recent edit to Steffan's answer. | |
| Jan 28, 2019 at 12:25 | comment | added | schroeder♦ | If the userID can be associated with a person, the userID becomes PII. If you can break the association, then that's great. But you cannot simply state that userID is sufficient. You need to have a structure that facilitates the disassociation. That means that the whole point is not about the userID at all, but rather how you process the data. | |
| Jan 28, 2019 at 12:23 | comment | added | schroeder♦ | @o.m. yes, and that's fine, but that's not what is being proposed by reed. These details are very important, and one cannot simply say that userID is sufficient. | |
| Jan 28, 2019 at 12:23 | comment | added | schroeder♦ | @reed I'm afraid GDPR disagrees with you. | |
| Jan 28, 2019 at 11:53 | comment | added | Anthony Grist | @o.m. I was just in the process of writing a similar comment (though you worded it much better than I was going to). It doesn't completely solve the problem, but it makes satisfying a request by a user to remove all of their PII much easier. | |
| Jan 28, 2019 at 11:51 | comment | added | o.m. | @schroeder, a randomly generated user ID can help to safeguard customer data if the rest of the PII is in just one table, because deleting that entry anonymizes the data in logs and similar places if you can no longer match that ID to a person. | |
| Jan 28, 2019 at 11:33 | comment | added | reed | @schroeder, of course it helps, because IDs have a much higher level of pseudonymity (I'd say 100%) than email addresses (which might even be enough to identify a person). And of course pseudonym data is still personal data. Pseudonymous data is not the same as anonymous data. | |
| Jan 28, 2019 at 11:15 | comment | added | schroeder♦ | If you need to log the email to verify email setup, then you can't get away from that | |
| Jan 28, 2019 at 11:14 | comment | added | schroeder♦ | user ID = email = PII in GDPR, so just switching to ID is not going to help | |
| Jan 28, 2019 at 10:58 | history | answered | reed | CC BY-SA 4.0 |