Does the IP logging + user data apply to GDPR? I read a lot about logging IP addresses, and it applies to GDPR: Do default Apache logs violate the GDPR? How to satisfy GDPR&#39;s consent requirement for IP logging? My question is slightly different. If I log a line like the following: TIMESTAMP | IP 123.123.123.123 | USER 42 | Serivice /country/list In this case, I would be able to relate the IP address to a single user by ID, so do I need to ask for an agreement before doing it?
IP addresses are personal data. That means you need a legal basis to process them, but not necessarily consent from the user. That IP addresses should be treated as personal data in most contexts is clear, regardless of whether you can associate the IP address with a user ID. That you make such an association affirms that both the IP address and user ID are personal data in your context though. As the answers in the questions you linked indicate, there are alternative legal bases to consent. The GDPR offers a choice of six legal bases (Art 6(1) lit a–f). In most cases, you would instead rely on a “legitimate interest” for logging. But it's not enough to claim that you have a legitimate interest. You must have a clear purpose for which such logs would be necessary, and you would then have to weigh this legitimate interest against the interests, rights, and freedoms of the affected data subjects. If such logs are necessary for security and anti-abuse purposes, your legitimate interest test is likely to prevail. However, you must limit retention of the logged data and the included information to what is actually necessary. For example, keeping user IDs in there might not be necessary. If the association of IP addresses and user IDs is not necessary for a legitimate interest, then you would indeed need consent. Discussion on why IP addresses are personal data. You see many answers and opinions that IP addresses might not be personal data. Some of these are technically correct, but most are misinformed or outdated. I know only a single well-informed person that still disagrees. For everyone else such as the EU Commission, IP addresses are clearly personal data. Under the GDPR, personal data is any information that relates to an (indirectly) identifiable natural person. In the context of log files we can assume that the entries usually “relate” to a person, namely the person making the request. The exception would be requests triggered by automated systems. The more interesting question is whether the person to which the log entry relates is identifiable. While the GDPR does provide further guidance on the concept of identification in Recital 26, it does not provide clear unambiguous criteria. Thus, there is lots of debate about what that precisely means. One approach is to sidestep that debate and and notice that the GDPR's definition of personal data explicitly notes that a person might be identified “in particular by reference to an identifier such as a name, an identification number, location data, an online identifier” (Art 4(1)). Another but otherwise unrelated part of the GDPR mentions “internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags” as examples of online identifiers (Recital 30). We can also look more deeply into Recital 26 and see that “singling out” already counts as identification. We can use the IP address to single out one person's log entries from the set of log entries, so this could be interpreted as meaning that any stable user ID renders the data personal data – and an IP address is sufficiently stable in this context. Another part of Recital 26 says that we must consider “all the means reasonably likely to be used” for identification, even if this involves additional information from third parties. This phrasing is virtually identical to the GDPR's predecessor, the EU Data Protection Directive. On the basis of that DPD, the EU's top court (ECJ/CJEU) was asked to rule on the question whether dynamic IP addresses are personal data (the Breyer case, C‑582/14, judgement from 2016-10-19). It said yes. “It did not say yes”, some people will object. And they are technically correct. When someone rents an internet connection from an ISP, the ISP will have logs that connect the user's real-world identity to the IP address they were assigned at a time. You don't have access to the ISP's logs. But, if that user violated your rights (e.g. a cyberattack or copyright infringement), then you could (depending on civil vs criminal matters) report this to the appropriate authorities or to petition the court and they would have the right to order the ISP to disclose this information. The CJEU said that if this chain (you → authorities → ISP → user identity) is grounded in law, then the IP address would be identifiable. But whether there are suitable laws to compel the ISP to disclose this data would be up to national laws, and the CJEU doesn't concern itself with that. Spoiler: such laws are pretty common. To summarize typical objections: The IP address doesn't relate to a person: Can be a valid objection, but is not typically the case for user-facing web services. The Recital 30 argument is not valid because it's about profiling, not identification, and it only says that IP addresses may be used for profiling, not that they are always identifying: Technically correct, but I think that Recital 30 merely expresses the implied understanding that of course an IP address is an online identifier and permits identification by itself. “Singling out” does not apply because SOME_REASON: Indeed, this is an ill-defined term with no case law to guide us. However, regulators such as the EDPB and their predecessor WP29 routinely use “singling out” to mean being able to distinguish one person's data from other people's data. An IP address lets us do that. The Breyer judgement is not applicable because the defendant in that case was the German state, and the state has other legal means than ordinary website operators: Nothing in that case was specific to the website operator being a state or other authority. If the website operator can contact the appropriate authority and if they have the right to order the ISP to disclose the relevant data, then the IP address is identifiable. The CJEU didn't say “yes” in Breyer, it said “if”. So I'll take that as a “no”: The CJEU concerns itself with the interpretation of EU law, not with national laws. Specifically in the Breyer case, lower courts confirmed that German law has the necessary means. In other EU member states, further checks would be necessary but it would surprise me if there wouldn't be equivalent subpoena powers. If the ISP doesn't have the data, then the IP addresses are anonymous: Indeed, the CJEU scenario collapses if there is no additional data to be linked with the IP address. However: The CJEU used this scenario as an example to show that IP addresses can be identifiable. If that particular scenario fails, there could be other scenarios that still allow identification. The question of whether IP addresses are identifiable had of course been the subject of wider debate at the time. That the GDPR explicitly mentions IP addresses can be seen as a reaction to this debate. Thus, in a sense, the Breyer case is moot. It is still useful as an explanation of how broad “reasonably likely means” must be interpreted.
Keeping logs of chats would not necessarily be against the GDPR as you have suggested. For the IRC service provider/operator: these chats/logs would be within scope if EU-based users are involved and this means the data controller/processors would have legal obligations to comply with GDPR. The IRC service provider/operator would be the data controller and would be held ultimately responsible for the data stored/processed through the IRC service, including backups and logs kept etc, and this would mean any sub-processors they select (such as hosting provider) would also have to be GDPR compliant. Due to the nature of IRC chats being entirely public in the same way forum board posts and comments are public, the contract terms between the IRC service provider and the IRC users would need to be very clear that this is the case, and the IRC users would need to give consent for this processing (this is more complicated for children, see Article 8 regarding consent from the holder of parental responsibility). For IRC users (personal use): If you wish to keep the chat records for personal use only (i.e. not in connection with a business or your employment at a business), then an exemption applies: This Regulation does not apply to the processing of personal data: ... (c) by a natural person in the course of a purely personal or household activity; ... (GDPR, Article 2: Material Scope, Paragraph 2(c), p.32) For IRC users (commercial/business use): In this case I don't think you would have any legal basis to store/process these chats/logs if they contain personal data without a legal agreement with the data controller which would require you to put in place the same protections they have to under GDPR but then allow your business to access the data for specific purposes. While the information may be published or considered to be in the 'public domain', for you to take a copy of it without permission and use it for a purpose they haven't consented to would not be allowed under GDPR. Additionally, to go through the process of removing personal data from the chats/logs would in itself be considered 'processing' under GDPR and therefore would be unauthorised without a legal agreement with the data controller. Practically therefore, your best options under this circumstance would be if: The IRC service provider implemented a 'favourites' feature to save within their own system the chat conversations you wish to retain and refer back to in future. Since they hold the data and you already have a user agreement with them there is no further complications (this is probably the best option); The IRC service provider implemented a feature to download an anonymized copy of a chat conversation (not ideal as there are no guaruntees a user will not include personal data in their messages, though the user agreement could state that message content will be considered to exclude personal data, in a similar way to how StackExchange do for this website, see the paragraph titled "Information You Choose to Display Publicly on the Network" on the StackExchange Privacy Policy). Your business considered an alternative communications solution, such as hosting its own real-time chat system or forum boards system, in which case your business would be the data controller, and while subject to GDPR you could then define the purposes for which the data will be used in your own user agreement.
Don't collect or process personal data Many (though of course not all) websites can easily be run without collecting or otherwise processing any personal data. The position of GDPR is that if you are not able to fulfil the basic, simplest core conditions for processing personal data (understanding what you're processing and why and why it's allowed, describing it in a privacy policy, having a non-underage person who's responsible for that) then you are not allowed to process personal data of other people. So don't. Build your website so that any personal data are not collected.
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
You are right that a visitor of a website does not expect to be tracked upon opening the website. But when using Google Analytics configured in the way explained in my other post, the visitor is not tracked. At least not in a way which violates the GDPR. You worry about the cookies. I also found this article which also does and suggests to either: change the _ga cookie to a session cookie, so it will be removed when the browser is closed. To do this, set the Cookie Expiration variable in your Google Analytics Settings to 0. completely disable cookies. (GA does not require cookies). To do this, set the storage field to none: ga('create', 'UA-XXXXX-Y', { 'storage': 'none' }); If you do not disable cookies, cookies can be used for tracking, which is more general defined in the GDPR as profiling. Profiling is defined in Art. 4 GDPR as: ‘profiling’ means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements; Art. 22(1) GDPR disallows profiling. Therefore in the settings menu from Google Analytics you have to disable data sharing and data collection. So data will only be used for the analytics function. But because you have configured to Anonymize your visitors IP Address, the part of the IP address used for this, is no longer considered personal data. This is because approx. 250 other users share the same part of the ip address which is stored, so data is not distinguishable between those 250 users. The anonymisation used by google is currently considered good enough. At least by the Dutch DPA. This might change if someone proves it is not good enough anonymized. Note that I am not a lawyer either, but I have read from multiple experts that analytics can be a "legitimate interest", the same way marketing can be a legitimate interest. This way configured the privacy impact is considered very low. It is also very important to note that a DPA consideres GA Google Analytics compliant. Even if a court would not agree in the future, you are acting in good faith if you follow those instructions, so you will probably not be fined. The DPA does currently not suggest to change the _ga cookie to a session cookie, or disable cookies completely. Note that the GDPR does not require doing anything to make it technical impossible to track someone. If a website has access to the data to track someone, but "promises" not to do that, that is fine. And rules regarding the usage of cookies in general, is not part of the GDPR, but (currently) part of the ePrivacy Directive. Only the way to ask for consent for storing cookies is defined in the GDPR.
The GDPR actually does require you to follow DNT in Article 21: In the context of the use of information society services, and notwithstanding Directive 2002/58/EC, the data subject may exercise his or her right to object by automated means using technical specifications. I think this is quite explicit.
Article 32 of the GDPR requires companies to adequately secure their data when handling data belonging to EU citizens. This also applies to cross border scenarios where data is transferred between countries. Technically speaking, the GDPR doesn't set a standard for security: you don't have to encrypt your data, use AES or RSA encryption, or hash and salt passwords. It is your choice on how to secure your data, though the GDPR does mandate specific ways to secure data. However, not doing so opens yourself up to two consequences: The European data protection supervisor is tasked with the enforcement of regulations. A company can be forced to increase their level security if a valid complaint alleging that inadequate security measures are in place is made There is a significant amount of security risk, and if a data breach occurs, the GDPR allows authorities to levy heavy fines. Especially heavy fines may occur if it is found that the data was not securely stored. So the answer is: A complaint to relevant authorities can force the company to take action, or they will lose access to the European market.
It seems clear that this is personal information under the GDPR. If you are subject to the GDPR, you need to have a "lawful basis" to store or process such information. (You are subject to the GDPR if you are locates in the EU, or if your users are. My understanding is that it is location at the time the app is accessed that matters, not a user's citizenship. I am not totally sure about that, however. Unless your app is limited to non-EU access, it it probably safest to comply with the GDPR) The degree of precision of your location data will not matter -- a specific city is quite enough to make it personal data if it can be tied to a specific person. There are various lawful bases that may be relied on for processing and storage, but explicit consent is probably the one with the widest applicability. To use consent as the lawful basis, you must present an OPT-IN decision to the user, and record the results. If the user does nothing, the result must record lack of consent. You may not use a pre-checked consent box or another mechanism that has the effect of an opt-out choice. You should be clear about what information will be stored, and how it will or might be used. You will also need to consider how your app will function for those who do not consent, and how to handle requests to withdraw consent. So if an app obtains user consent to store location data in a manner that complies with the GDPR, it may store user location data. The consent should make the possible uses of the data clear. If the data is to be shared, the consent should make the possible extent of sharing clear. Some previous questions and answers here on law.se dealing with GDPR consent that seem possibly relevant: User consent required under GDPR What provisions should I make regarding GDPR consent when users do not sign themselves up? GDPR - Withdrawn user consent Opt Out Consent under GDPR