3 ms·

Note: if your fingerprint can be used to identify a specific person in combination with other data (it can be), you're still subject to GDPR on this (assuming y

Note: if your fingerprint can be used to identify a specific person in combination with other data (it can be), you're still subject to GDPR on this (assuming you're within jurisdiction). It's probably entirely reasonable that, given the salt that gets regenerated each midnight (and which is stored separately from the dataset), and the lack of further processing done on the dataset to match it with specific people, this is a legitimate interest, but you'll still have to mention it in your privacy policy.

marvinblum 6y ago
Can you explain how a person can be identified by the fingerprints I'm generating? I know it's possible to track the page flow of individual visitors, but as Pirsch does not store the IP or any information that is unique to someone, I don't know how I could trace that back to a person.
- vertex-four 6y ago
  If you have the IP and user agent in some other system (for example, if the user hits your website again, or if they make an access request where you could verify this data), you could take the salt out of Pirsch and combine the three to regenerate your fingerprint, thus tying the hit data to the user. The fact that the salt exists entirely in-memory within a defined system (unless it were, for example, within an HSM which would be extremely difficult to get the salt out from) would seem to be irrelevant to the definition of personal data within the GDPR - although I'd be interested to see discussion of that. The data stops being personal data once you drop the salt entirely. I'm also fairly certain that a trace of a single user from A through B (e.g. they hit the "payment confirmed" page at a specific time, having hit a specific product page before) could be correlated with a user in a purchases/shipping database and from there to a name and address, depending on the overall system Pirsch gets used in. Bringing separate datasets into the same tooling to query them isn't particularly hard. If it's used on a simple blog with no other tracking or systems that store this data, this argument probably doesn't hold water. Pseudonymising data at the earliest possible point fulfils another part of the GDPR (to do with controls and protection of personal data), but doesn't in itself make something not personal data, according to the UK's ICO. Recital 26 of the GDPR states - "To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments." But the fact of the matter is that there is so little risk here that it's likely to be a legitimate interest for the vast majority of businesses, thus not requiring consent (but still requiring adherance to the rest of the GDPR on personal data), again according to the ICO.
  - marvinblum 6y ago
    Thanks for the explanation. I guess I should add a secret to the generated hash. That would prevent anyone without access to it to regenerate a similar hash. As you said it's still a good idea to inform the visitors about the anonymous tracking. I'm pretty sure that most websites require a cookie note anyway, no matter how annoying it might be.
    - vertex-four 6y ago
      Most websites probably don't actually need a cookie notice, at least up-front - cookies that are "strictly required" for the website to function and are not used for non-required functionality are exempt, something that most people miss because the vast amount of discussion around this is around user-tracking advertising.

marvinblum 6y ago

Can you explain how a person can be identified by the fingerprints I'm generating? I know it's possible to track the page flow of individual visitors, but as Pirsch does not store the IP or any information that is unique to someone, I don't know how I could trace that back to a person.

vertex-four 6y ago
If you have the IP and user agent in some other system (for example, if the user hits your website again, or if they make an access request where you could verify this data), you could take the salt out of Pirsch and combine the three to regenerate your fingerprint, thus tying the hit data to the user. The fact that the salt exists entirely in-memory within a defined system (unless it were, for example, within an HSM which would be extremely difficult to get the salt out from) would seem to be irrelevant to the definition of personal data within the GDPR - although I'd be interested to see discussion of that. The data stops being personal data once you drop the salt entirely. I'm also fairly certain that a trace of a single user from A through B (e.g. they hit the "payment confirmed" page at a specific time, having hit a specific product page before) could be correlated with a user in a purchases/shipping database and from there to a name and address, depending on the overall system Pirsch gets used in. Bringing separate datasets into the same tooling to query them isn't particularly hard. If it's used on a simple blog with no other tracking or systems that store this data, this argument probably doesn't hold water. Pseudonymising data at the earliest possible point fulfils another part of the GDPR (to do with controls and protection of personal data), but doesn't in itself make something not personal data, according to the UK's ICO. Recital 26 of the GDPR states - "To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments." But the fact of the matter is that there is so little risk here that it's likely to be a legitimate interest for the vast majority of businesses, thus not requiring consent (but still requiring adherance to the rest of the GDPR on personal data), again according to the ICO.
- marvinblum 6y ago
  Thanks for the explanation. I guess I should add a secret to the generated hash. That would prevent anyone without access to it to regenerate a similar hash. As you said it's still a good idea to inform the visitors about the anonymous tracking. I'm pretty sure that most websites require a cookie note anyway, no matter how annoying it might be.
  - vertex-four 6y ago
    Most websites probably don't actually need a cookie notice, at least up-front - cookies that are "strictly required" for the website to function and are not used for non-required functionality are exempt, something that most people miss because the vast amount of discussion around this is around user-tracking advertising.