Help figuring out GDPR and pseudonymisation
<p>I have server that needs to identify returning visits from users. I'm trying to figure out what I can do and whether I'm supposed to ask for consent from the user.</p>
<p>I don't care who the actual user, let's say I want to know the last date of his visit.</p>
<ol>
<li><p>I know I can set a cookie, but I will have to ask for consent.</p>
</li>
<li><p>I thought about saving the ip + userAgent + additional data in a hashed way - pseudonymisation.
my plan is to hash the ip but the ua + other data as the salt for the hash. that would be my key and the value is the date of the visit.
that way I have no idea to know who the user is, or how to restore this data. I will be able to know that last visit only if the user sends a request again with the same ip,ua, etc...</p>
</li>
</ol>
<p>Does that require consent from the user or just mentioning that in the privacy policy on my website?</p>
<ol start="3">
<li>I saw google is anonymizing ip by masking it. so if I'll do the same Im creating a record that is no longer matched with just 1 user, it can be matched to many (depending on the ip mask). Does that require consent? what mask is enough? 1 bit? 8 bits?</li>
</ol>
<p>What is important to mention that the data I save for each user is not unique to him. with the example above I will get multiple users that have the same value stored for them, since they visited the same day. So again, I don't see a way anyone could track these users.</p>
<p>I've listed my options from the most accurate to the least. If there are other options I'd appreciate your help.</p>
<p>Thanks.</p>

<p>Your question touches on two closely related compliance issues, GDPR and ePrivacy. An analysis of the GDPR situation suggests that all of your alternatives involve processing of personal data, but that (depending on processing purpose) consent may not be required. However, ePrivacy most likely does require consent in your case, even when avoiding cookies.</p>

<p><strong>GDPR</strong> is fairly flexible and straightforward. For compliance, you must have a legal basis. I recommend starting with these three questions:</p>

<ol>
<li><p><strong>What is the purpose of processing?</strong></p>

<p>Answering this question accurately is a necessary prerequisite for the other questions. The same data processed for different purposes can have different compliance obligations.</p></li>
<li><p><strong>What is the legal basis for this purpose?</strong></p>

<p>Possible legal bases are enumerated in GDPR Art 6. The most important are:</p>

<ul>
<li>consent</li>
<li>necessity for performance of a contract with the data subject</li>
<li>legal obligation per EU or member state law</li>
<li>legitimate interest</li>
</ul>

<p>In the context of online tracking, only consent (opt-in) or legitimate interest (opt-out) are likely to apply.</p>

<p>Legitimate interest requires you to perform a balancing tests between these interests and the rights and freedoms of the affected data subject. Sometimes, implementing additional safeguards can tilt the balance in your favour.</p></li>
<li><p><strong>What is the minimum data necessary to achieve the purpose?</strong></p>

<p>Per the GDPR's data minimization principle, you can only process personal data to the degree that it is necessary for a specific purpose. Collecting more data might require another legal basis, e.g. consent.</p>

<p>If the processing purpose can be achieved with pseudonymized data, pseudonymization is mandatory and will not affect a legitimate interest balancing test.</p></li>
</ol>

<p>It is important to note that pseudonymized data is still personal data because it still enables re-identification. If direct and indirect re-identification is impossible it can be considered anonymized data that no longer falls under the GDPR. However, anonymization is extremely difficult in practice, so this route should not be relied on to “escape” from GDPR compliance.</p>

<p>A couple of notes in this context:</p>

<ul>
<li><p>Google Analytics uses terms with different meaning than in the GDPR. E.g. GA clearly collects personal data (including identifying information), but the terms of service prohibit you from uploading PII. The <code>anonymize_ip</code> function that truncates IP addresses is likely just a pseudonymization mechanism that doesn't achieve anonymization, especially since the truncated IP address is combined with other information. But the use of this function is still mandatory due to the data minimization principle.</p></li>
<li><p>Your proposed solution of hashing a user agent signature into a fingerprint is generally sensible since it makes the individual inputs unreadable. When processed for some purposes, this fingerprint might even be anonymous.</p>

<p>However, your purpose is re-identification of visitors. Only the storage of seen fingerprints involves pseudonymized data, but generating and checking this fingerprint clearly involves processing of personal data. Thus, GDPR applies.</p>

<p>GDPR does not prescribe a legal basis to be used for cookies or browser fingerprints, and there is an argument that cookies or re-identification (on the same site only) could fall under a legitimate interest. But read on.</p></li>
</ul>

<p>The <strong>ePrivacy directive</strong> is famous for its cookie consent requirement. However, it is more broadly about privacy in electronic communications. While it has clear prescriptions, they don't actually apply directly. Instead, every EU member state has its own implementation of the directive. These laws differ in some details, so you must check the variant in your member state.</p>

<p>Traffic data is any data that is necessary for performing a transmission. For a website, this includes IP metadata such as IP addresses, or HTTP metadata such as headers and cookies. Any processing of traffic data that goes beyond what is necessary is allowed only when (a) the data was anonymized, or (b) the user has consented. As discussed above, true anonymization is difficult to impossible, at least in your use case. Important consequences:</p>

<ul>
<li>it makes no difference here whether your store an ID in a cookie or whether you use HTTP headers to fingerprint the browser</li>
<li>in either case, consent is required</li>
</ul>

<p>Especially with regards to purposes such as cookie-based analytics, we have the awkward situation that the processing itself may fall under a legitimate interest, yet ePrivacy mandates consent. There was an attempt to overhaul ePrivacy in time for the GDPR, but that effort hasn't made any progress since 2017.</p>

<blockquote>
  <p>Does that require consent from the user or just mentioning that in the privacy policy on my website?</p>
</blockquote>

<p>Apparently neither.</p>

<p>Article 4(1) defines the concept of <em>personal data</em>, and recital 26 of the <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679" rel="nofollow noreferrer">GDPR</a> explains that "<em>[p]ersonal 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</em>".</p>

<p>Accordingly, your data system seems to fall outside the scope of the GDPR insofar as your procedure precludes the possibility of identifying a natural person. Item 2 in your post and your remark that "<em>the data [you] save for each user is not unique to him</em>" suggest that that is the case. Therefore, there is no need for users' consent or awareness.</p>

gdpr