0

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.

I don't care who the actual user, let's say I want to know the last date of his visit.

  1. I know I can set a cookie, but I will have to ask for concent.

  2. 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...

Does that require consent from the user or just mentioning that in the privacy policy on my website?

  1. 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?

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 can track these users.

I've listed my options from the most accurate to the least. If there are other options I'd appreciate your help.

Thanks.

  • Whether GDPR requires you to get consent from the user depends in part on whether you have another basis for the processing. This in turn depends on the reason for your need to identify returning users. – phoog May 13 at 3:48
0

Does that require consent from the user or just mentioning that in the privacy policy on my website?

Apparently neither.

Article 4(1) defines the concept of personal data, and recital 26 of the GDPR explains that "[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".

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 "the data [you] save for each user is not unique to him" suggest that that is the case. Therefore, there is no need for users' consent or awareness.

| improve this answer | |
  • If the data has been successfully pseudonymized, further processing of pseudonymized data would fall outside of the GDPR. But the pseudonymization process itself does involve personal data, thus requiring a legal basis. And regardless of whether this is personal data, ePrivacy still applies when processing traffic data – this possibly requires consent. – amon May 12 at 11:28
  • @amon Your remark on ePrivacy is something the OP should ponder. I am just not knowledgeable of it to say whether or not it is worth to spend nearly as many resources as companies are devoting to the GDPR mess. As for your point on pseudonymization, the issue is not whether the process involves personal data, but whether the system stores it. See recital 15 ("[t]he protection should apply to the processing of personal data [...] if the personal data are contained or are intended to be contained in a filing system"). Per OP's 2nd-to-last paragraph, he is not really keeping personal data. – Iñaki Viggers May 12 at 11:53
  • Thanks @IñakiViggers. so as far I can understand from your answer option 2 is good enough to not ask for consent. What about option 1? all cookies ask for consent and opt in form or since the data I store on the cookie is not unique to any specific user I can set that cookie with out asking the user? Thanks again. – dor272 May 12 at 12:37
  • @dor272 Option 2 is safer from the GDPR standpoint than option 1 because cookie identifiers are considered online identifiers that can be associated to a natural person. See recital 30. Thus, with option 1 you not only would need user's consent, but it might also invite GDPR scrutiny notwithstanding your knowledge that such cookie is not uniquely traceable to a specific user. By contrast, hashing seems much, much harder to reverse [than restoring data under a cookie approach] and does not require user's consent. – Iñaki Viggers May 12 at 13:35
0

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.

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

  1. What is the purpose of processing?

    Answering this question accurately is a necessary prerequisite for the other questions. The same data processed for different purposes can have different compliance obligations.

  2. What is the legal basis for this purpose?

    Possible legal bases are enumerated in GDPR Art 6. The most important are:

    • consent
    • necessity for performance of a contract with the data subject
    • legal obligation per EU or member state law
    • legitimate interest

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

    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.

  3. What is the minimum data necessary to achieve the purpose?

    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.

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

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.

A couple of notes in this context:

  • 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 anonymize_ip 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.

  • 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.

    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.

    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.

The ePrivacy directive 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.

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:

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

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.

| improve this answer | |
  • Thanks for your detailed explanation. In my case the data mentioned above that I intend to hash is to detect the country origin of the visitor. the data I save as I said is hashed and can't be restored. value is the date. so I'll end up with bunch of hashes that store the same date for example '05/13/2020'. that is the only information saved for a visitor. so the re-identification just assigns him to a group of people, that I stored for them '05/13/2020'. don't see how that is possible to link it to a "natural person". – dor272 May 13 at 6:13
  • I don't think it's clear from question or your answer that OP can identify a natural person given their IP address and user agent string. So how does GDPR apply? – Lag May 13 at 7:20
  • @dor272 If you are merely collecting aggregate statistics (e.g. count visitors from each country) then that is anonymous data and you don't need consent. But the process you describe is more like a browser fingerprint, which clearly is personal data within the scope of the GDPR, even if you can't directly identify a natural person from the fingerprint. I'm not sure how the date factors in to this process. If you can edit your question with more a detailed explanation (possibly as pseudocode) I can provide a better response. – amon May 13 at 10:27
  • @Lag You're interpreting “identifiable” too narrowly. While a browser fingerprint is not directly identifying, it can be used to match a natural person to a record, thus re-identifying the pseudonymous data. GDPR Art 11 discusses processing without identifying information: the GDPR still applies, but specific data subject rights don't, unless the data subject provides data necessary for re-identification. Recital 26 discusses the difference between pseudonymous and anonymous data: it's still personal data if it can be re-identified with additional information or if a person can be singled out. – amon May 13 at 10:37
  • " While a browser fingerprint is not directly identifying, it can be used to match a natural person to a record" - by what means? – Lag May 13 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.