11

I create a script, which asks a user who upload a GIF to a social media website, if it can reupload it to another website (to reduce other users' internet usage). Now I want to give users an option to save their consent for a longer time, so they don't need to click a link every time they upload a GIF. Users don't have a random ID, I only can use their usernames, which are surely personal data (many users use their Facebook account to create their account, and then their usernames are created from their first and last name).

So my question is - if I store a hash of the usernames (irreversible form), is it still considered to be their personal data?

Improve this question

2 Answers 2

Reset to default
7

It depends on whether you can identify the person to whom a username hash belongs.

If you store both username and its hash in the same database row then yes.

If it is impracticable for you to identify the person by their hash only, then no.

This comes from the definition of personal data — "any information relating to an identified or identifiable natural person", and Recital 26: Not applicable to anonymous data. The hash is essentially anonymous data when it does not on its own allow to identify the person (with reasonable efforts i.e. without spending $$$ on detectives or forensic science).

Improve this answer
8
  • 1
    @Viktor answer updated.
    – Greendrake
    Jun 25, 2018 at 0:40
  • 1
    I think I was unclear. What i meant to say is if you store the hash and link it with other data (like what pictures this user posted) and store it in a database this would still be covered because it would be possible in the future (even if you do not intend to do this) for someone else to take a list of users and the hashes and then link the pictures to the users.
    – Viktor
    Jun 25, 2018 at 1:08
  • 1
    @Viktor I would say if the links between users and pictures are kept outside of your organisation (that keeps the links between hashes and pictures), the effort needed to map the hashes to users would be high enough so that the hashes are not considered personal data. But this would be case-by-case and up to judges to decide.
    – Greendrake
    Jun 25, 2018 at 1:17
  • 3
    I disagree with the above comment. It is computationally infeasible to determine the input that produces a particular hash, assuming zero knowledge of the input. If you know that the input is a Facebook username, then it is quite easy to hash all existing usernames (there are only a few billion). It may be difficult to compile a list of all Facebook usernames, but you could certainly scrape a few hundred million. I would be very unhappy if my personal data was pseudonymised using this method.
    – sjy
    Jun 25, 2018 at 8:56
  • 2
    @sjy 1) You'd need to know the hash function + salt used; and 2) Who said it's Facebook? But yes, there can be cases where finding out persons from hashes is simple enough to be worried.
    – Greendrake
    Jun 25, 2018 at 9:19
7

The Art. 29 WP has released Opinion 05/2014 on Anonymisation Techniques. There it defines a hash function like this:

Hash function: this corresponds to a function which returns a fixed size output from an input of any size (the input may be a single attribute or a set of attributes) and cannot be reversed; this means that the reversal risk seen with encryption no longer exists. However, if the range of input values the hash function are known they can be replayed through the hash function in order to derive the correct value for a particular record. For instance, if a dataset was pseudonymised by hashing the national identification number, then this can be derived simply by hashing all possible input values and comparing the result with those values in the dataset. Hash functions are usually designed to be relatively fast to compute, and are subject to brute force attacks. Pre-computed tables can also be created to allow for the bulk reversal of a large set of hash values.

The use of a salted-hash function (where a random value, known as the “salt”, is added to the attribute being hashed) can reduce the likelihood of deriving the input value but nevertheless, calculating the original attribute value hidden behind the result of a salted hash function may still be feasible with reasonable means.

So a hash function is considered pseudonymisation, not anonymisation. Pseudonymised data is still personal data. See also art.4 GDPR which contains definitions of ‘personal data’ and ‘pseudonymisation’.

In your question you say you want to give users an option to save their consent for a longer time. So you use a hash to identify such a user. That implies that you are able to identify a user, so it is personal data. That does not mean your processing is unlawful. If you make it clear to users you save their consent when they select that option, they implicitly also give consent to the saving itself, so art. 6(1)(a) applies. But also art. 6(1)(b) would probably apply.

Art. 25 and Art. 32 encourage the use of pseudonymisation when processing personal data.

The above would only apply if the hash function generates a unique hash for each input. If you use a hash function where different inputs generate the same hash, it would not be considered aggregation (or generalization). Art. 29 WP has also written about that in their Opinion 05/2014 on Anonymisation Techniques. See the topic on "Aggregation and K-anonymity" (3.2.1). So even aggregation does not allow effective anonymisation in all cases.

Improve this answer
3
  • 1
    "The above would only apply if the hash function generates a unique hash for each input. If you use a hash function where different inputs generate the same hash, it would not be considered aggregation (or generalization)." Most hash functions cannot generate unique hashes for all possible inputs as the output is smaller than the possible input.
    – JAB
    Oct 8, 2018 at 19:06
  • 2
    @JAB True, but a username is a relatively small input. In this case a hash is used for a unique ID identifying a person. It is estimated that the world population is 7.6 billion people. If everybody has a single unique username, the input would basically be 33 bits. For example SHA-256 produces a 256 bits output which is much more. Collisions are still possible, but unlikely.
    – wimh
    Oct 8, 2018 at 19:50
  • 1
    But it is more likely than it seems: en.m.wikipedia.org/wiki/Birthday_problem
    – Fabian Barney
    Oct 15, 2018 at 20:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .