Law Stack Exchange is a question and answer site for legal professionals, students, and others with experience or interest in law. It only takes a minute to sign up.
Sign up to join this community
Is the following pseudo code, being executed within the browser, compatible with GDPR?
sha256(fonts + useragent + plugins + ..)
Notice: It doesnt store the actual attributes on the server, only the hash of these is transferred, so that the server cant conclude what the real values were.
The hash you produce is linked to one (or a small number) of computers and it therefore serves as an ID number. Because that ID number is linked to the owner of the computer it is personal information and if you are collecting it, you must comply with the requirements of the GDPR - valid legal reason, deletion when no longer required, deletion on request, data security etc.
There are two concerns here: GDPR and ePrivacy. Such fingerprints are personal data. It is likely that you would need to get the user's consent before creating the fingerprint.
Per the GDPR, personal data is any information relating to an identifiable natural person. Per Recital 26, being able to single out a person (in a larger dataset) already implies identifiability. Thus, also taking into account pre-GDPR regulator's guidance such as Opinion 9/2014 on the application of Directive 2002/58/EC to device fingerprinting (PDF), it must be assumed that even this hashed fingerprint is personal data. They write:
It has been noted in Opinion 16/2011 that advertising companies have argued that the use of unique codes or other values does not involve the processing of personal data. This is in contradiction to the purpose of processing for the delivery of personalised content and advertisements, i.e., to communicate directly with a specific individual. The Working Party has argued on many occasions that such unique identifiers qualify as personal data.
The same conclusion still holds in 2022: fingerprints serve identification purposes and are therefore clearly personal data.
If the GDPR applies, you need a clear purpose and legal basis for this fingerprint. In some cases, you might have a legitimate interest for using such identifiers. However, ePrivacy requires you to ask for consent instead.
Per ePrivacy, you may only access information stored on an end user's device if this is strictly necessary for performing a service explicitly requested by the user, or if this access is necessary for technical reasons (e.g. browser caching is legal), or if the user has given consent. Fingerprinting is not going to be strictly necessary. But your suggested fingerprint definitely involves accessing information stored on the user's device, such as available fonts and plugins. Thus, creating such a fingerprint would require the user's freely given consent, where conditions for consent are given in Art 7 GDPR.
A fingerprint that is based solely on HTTP metadata received by a server (e.g. useragent + IP address) could be argued to be legal in some cases even without consent.
So from the ePrivacy perspective, fingerprints and cookies are generally equivalent and follow the same rules: consent is required unless they are strictly necessary. Business needs do not fulfill this “strictly necessary” criterion. If you already have to ask for consent, it is typically much easier to create a cookie with a random ID than to create some complicated fingerprinting scheme.
