gdpr european-union
Storing IP&#39;s and GDPR Compliance
<p>Suppose a web designer plans to store hashed IP's in a database for analytical purposes of tracking unique clicks, and for security purposes to prevent botting unique clicks. Suppose the site only stores one-way hashes of the IP addresses, and only for as long as the data is needed. The plan is to allow Users can also contact the site to remove their data entirely.</p>
<p>Would such a design be GDPR compliant?</p>
<p>I've read a lot of mixed commentary on whether this type of use case would be allowed, and any sources to support your reasoning would be appreciated.</p>

<p><a href="https://gdpr-info.eu/art-4-gdpr/" rel="noreferrer">GDPR Article 4</a> paragraph 1 says:</p>
<blockquote>
<p>‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;</p>
</blockquote>
<p><a href="https://gdpr-info.eu/recitals/no-26/" rel="noreferrer">Recital 26</a> says</p>
<blockquote>
<p>Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. ... The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.</p>
</blockquote>
<p><a href="https://gdpr-info.eu/recitals/no-30/" rel="noreferrer">Recital 30</a> says:</p>
<blockquote>
<p>Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.</p>
</blockquote>
<p>An IP address hashed through a cryptographically secure one-way hash cannot reasonably be used to establish the original IP address, nor to geolocate, nor to directly identify the data subject. However if such addresses are stored in a database with a link to the subject's individual record, or to other data which identify the data subject, then they would clearly be personal information.</p>
<p>The ICO's page on <a href="https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/what-is-personal-data/" rel="noreferrer">&quot;What is personal data&quot;</a> says:</p>
<blockquote>
<p>‘Online identifiers’ includes IP addresses and cookie identifiers which may be personal data.</p>
</blockquote>
<p>The <a href="https://gdpr.eu/eu-gdpr-personal-data/" rel="noreferrer">page from GDPR.EU on &quot;Personal Data&quot;</a> says:</p>
<blockquote>
<p>Any information that can lead to either the direct or indirect identification of an individual will likely be considered personal data under the GDPR. ... Any data that relate to an identifiable individual is personal data.</p>
</blockquote>
<p><a href="https://gdpr-info.eu/issues/personal-data/" rel="noreferrer">The page on &quot;Personal Data&quot; from gdpr-info.eu</a> says:</p>
<blockquote>
<p>Personal data are any information which are related to an identified or identifiable natural person.</p>
</blockquote>
<blockquote>
<p>The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data.</p>
</blockquote>
<blockquote>
<p>Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice ...</p>
</blockquote>
<p>See also <a href="https://www.fieldfisher.com/en/services/privacy-security-and-information/privacy-security-and-information-law-blog/can-a-dynamic-ip-address-constitute-personal-data" rel="noreferrer">&quot;Can a dynamic IP address constitute personal data?&quot;</a></p>
<p>If a hashed IP address is stored so that it can be related to a specific individual, it is personal data. as such, it would be subject to the GDPR. To store it one would need to identify a lawful basis under <a href="https://gdpr-info.eu/art-6-gdpr/" rel="noreferrer">GDPR Article 6</a> This could be the Data subject's consent, or the Controller's legitimate interest. In either case the information should be included in the list of personal information collected (often in a privacy policy document), disclosed to the subject on request, adn deleted on request if possible. If that is done, such a use of a hashed IP, although personal information, would seem to be compliant.</p>
<p>If a hashed IP is stored in such a way that it cannot be related to any particular user, then it would not constitute personal information, and no compliance issue would seem to exist.</p>
<p>Limiting the retention time of a hashed IP is a good practice which would reduce any possible impact it might have.</p>

<p>This kind of hashing is not anonymization, so your hashed IP addresses do likely count as personal data. It is good that you're using hashing as an added safety measure, but it's still personal data and as thus subject to the GDPR.</p>
<p>Why is it personal data? By definition, you are using these hashes in order to re-identify visitors. For this purpose, hashing vs no hashing makes no difference, it is the IP addresses that matter. But let's say that there were a difference. GDPR does count data as anonymized if the data subject can't be reidentified with any means reasonably likely to be used. However, a hash function is only as strong as its input. There are only 4.3 billion IP4 addresses. This can be trivially bruteforced within a few CPU-minutes, even for a cryptographic hash function.</p>
<p><sub>Source: Personal experiments with SHA1 of stringified IP4-addresses indicate 2.6 million hashes per CPU-second on Zen-2 architecture. This means we can expect to crack the hash after one or two minutes on a mid-range desktop CPU. Not unreasonably costly.</sub></p>
<p>So let's ignore the hashing and focus on when you can use IP addresses.</p>
<p>IP addresses are generally personal data in the sense of the GDPR. While there was some dispute about this pre-GDPR, the GDPR explicitly calls out “internet protocol addresses”. You can process IPs if you have a legal basis such as a legitimate interest, and have to comply with transparency requirements such as those in Art 13 GDPR.</p>
<p>But IP addresses are also “traffic data” in the sense of the ePrivacy directive. Unfortunately, every EU member state and the UK have their own implementation with slightly different requirements. Per ePrivacy Art 6, you can only use traffic data:</p>
<ul>
<li>for the purpose of a “transmission”,</li>
<li>when anonymized,</li>
<li>for billing purposes,</li>
<li>or when the user has given their consent.</li>
</ul>
<p>Furthermore, you must inform users about the types of traffic data which are processed, and about the duration of processing (how long you are keeping this data). This overlaps with GDPR requirements.</p>
<p>Here, it is probably straightforward to argue that security measures like keeping bots out are necessary for providing your service or for proper billing of the user. You can likely do whatever is <em>necessary</em> for those purposes.</p>
<p>Using (hashed) IPs for analytics purposes is more difficult to argue. Analytics or ads are not necessary to provide your service. Such fingerprinting measures would generally require the user's consent, similar to setting a cookie with a user ID.</p>
<p>Of course, no one does this properly. Unannounced ingerprinting is extremely common, as is the claim that hashing would lead to anonymization. But “everyone else does it” doesn't mean it's legal.</p>
